2016-12-28 25 views
-1

虽然我搜索了很多,但无法找到相同的合理答案。 为什么serialrialuid不能加倍?保持serialversionuid长的任何具体原因?为什么Serialrialuid在java中很长?

+3

为什么有一个类型为double的id有用? – Hulk

+0

因为'Serializable'的javadoc是这样说的吗? – assylias

+0

因为'long'具有更多的精度。因为“长”是确切的。因为“double”的小数部分不是必需的。因为没有人会尊重“双”的优势。由于[Javadoc](http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html)和[对象序列化规范](https://docs.oracle.com) /javase/8/docs/platform/serialization/spec/class.html)这样说。 – EJP

回答

3

一个唯一的ID通常是一个随机选择的整数。例如UUID是两个很长的值。

使用double是非常困难的,因为并非所有的64位值都在Java中使用,并且某些值不等于它们自己。 Double.NaN。

顺便说一句,如果你真的想使用double你能做到这一点

private static final long serialVersionUID = Double.doubleToRawLongBits(1.28); 

但使用浮点值将有我不知道还有什么价值。如果要编码的版本号,你可以做到这一点

private static final long serialVersionUID = MAJOR * 1000 + MINOR; 
0

一个UID的东西,必须是在序列化给定的背景下独特的,因为它通常由集成开发环境或计算产生的Serializable实例时,程序员。对于应该是唯一的东西,long数据类型似乎是合理的。合理,因为它是一个隐含的数据类型,并且是double旁边最大的一个。数据类型越大,生成唯一ID时出现冲突的几率就越低。 (想象一下,使用byte作为serialVersionUID的数据类型,您将只有256个可用值来生成“唯一”ID,这将导致很多冲突)。数据类型double与其他double值有其自身的问题。 long没有这样的问题。另一方面,使用String或其他参考类型可能不合适,因为在空间和时间复杂性方面它可能是昂贵的。所有这些原因使得long成为使用它作为serialVersionUID的数据类型的合理选择。

有关更多信息,请参阅this article。我也提取了一些相同的东西。

序列化运行时相关联,每个序列化类版本号,称为的serialVersionUID,其被反序列化过程用于验证序列化对象的发送者和接收者都加载的类该对象是相对于兼容序列化。如果接收者已经为与对应的发送者类具有不同serialVersionUID的对象加载了类,则反序列化将导致InvalidClassException。可序列化类可以通过声明名为“serialVersionUID的”字段必须是静态的,最终明确宣布了自己的serialVersionUID,并键入长:

ANY-ACCESS-MODIFIER static final long serialVersionUID = 42L; 

如果一个序列化类没有显式声明的serialVersionUID ,那么序列化运行时将基于该类的各个方面计算该类的默认serialVersionUID值,如Java(TM)对象序列化规范中所述。但是,强烈建议所有可序列化的类显式声明serialVersionUID值,因为默认的serialVersionUID计算对类详细信息高度敏感,这可能因编译器实现而异,因此在反序列化期间可能会导致意外的InvalidClassException。因此,要确保跨不同的java编译器实现保持一致的serialVersionUID值,可序列化的类必须声明显式的serialVersionUID值。还强烈建议显式serialVersionUID声明尽可能使用private修饰符,因为这些声明仅适用于立即声明的类 - serialVersionUID字段作为继承成员是无用的。数组类无法声明显式的serialVersionUID,因此它们始终具有默认的计算值,但是对于数组类而言,不需要匹配serialVersionUID值。

希望这会有所帮助!

相关问题