为什么Serialversionuid在java中很长?

时间:2016-12-28 08:32:05

标签: java serialization interface long-integer

虽然我搜索了很多但却无法找到合理的答案。 为什么serialversionuid不能加倍?保持serialversionuid长的任何特定原因?

2 个答案:

答案 0 :(得分:3)

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

使用double要困难得多,因为并非所有64位值都在Java中使用,并且某些值不等于它们自身,例如Double.NaN。

顺便说一句,如果你真的想使用Observable<Boolean> deleteFile = rxDrive.delete(file); Observable<Void> syncDrive = rxDrive.sync(); Observable.concat(deleteFile, syncDrive); ,你可以这样做

double

但我不知道使用浮点值会有什么价值。如果要对版本号进行编码,可以执行此操作

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

答案 1 :(得分:0)

UID在给定的序列化上下文中必须是唯一的,因为它通常由IDE或程序员在创建Serializable的实例时计算。对于应该是唯一的内容,long数据类型似乎是合理的。合理的原因是,它是一个隐式数据类型,是double侧可用的最大数据类型。数据类型越大,生成唯一ID时发生冲突的可能性就越小。 (想象一下,使用byte作为serialVersionUID的数据类型。您将只有256个可用值来生成&#34;唯一&#34; ID会导致很多冲突)。 double数据类型有其自身的问题,可与其他double值进行比较。 long没有此类问题。另一方面,使用String或其他参考类型可能不合适,因为它在空间和时间复杂性方面可能是昂贵的。所有这些原因使得long成为serialVersionUID的数据类型的合理选择。

有关详细信息,请参阅this article。我也从中提取了一些比特。

  

序列化运行时将每个可序列化类与版本号相关联,称为serialVersionUID,在反序列化期间使用该版本号来验证序列化对象的发送方和接收方是否已加载与该序列化兼容的该对象的类。如果接收者已经为具有与相应发送者类的serialVersionUID不同的serialVersionUID的对象加载了类,则反序列化将导致InvalidClassException。可序列化类可以通过声明名为&#34; serialVersionUID&#34;的字段来显式声明其自己的serialVersionUID。必须是static,final和long类型:

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

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

希望这有帮助!