生成serialVersionID而不是1L,2L的好处,

Seb*_* S. 6 java serialization serialversionuid

我与一位同事讨论了可序列化类的serialVersionUID:他总是从a开始,serialVersionUID = 1L然后在对类进行一些重大更改时将其递增1.

JDK类似乎总是在类中使用更复杂的生成的serialVersionUID java.lang.String:

private static final long serialVersionUID = -6849794470754667710L;
Run Code Online (Sandbox Code Playgroud)

现在,我的同事询问这种serialVersionUID与简单的serialVersionUID(如1L,2L,3L ......)相比的优势?

我们还搜索了SOF,但对给出的答案不是很满意,例如在为什么生成long serialVersionUID而不是简单的1L?.

在我看来,使用生成的ID的优点是它不需要任何有关"旧"类版本的信息.但是当手动递增ID时,您必须知道到目前为止的最高值.这可能听起来微不足道(通过查看当前的serialVersionUID并将其增加1),但在更大的软件项目,更大的开发团队或分布式环境中可能更复杂.

use*_*421 1

使用生成的版本的优点是,如果该类已逃逸而没有serialVersionUID进入野外,则它与该类的先前版本兼容。

话虽如此,你的同事增加它几乎肯定是错误的。serialVersionUID仅当您接受类已发生不可挽回的更改并且您有意引入序列化不兼容性时,才应更改。这种情况在自然界中发生的情况很少见,仅限于以不兼容的方式更改类的继承或成员字段的类型的情况。如果你决定开设一门课程,那么Serializable你应该已经接受了一种不会发生这种情况的制度。