我与一位同事讨论了可序列化类的serialVersionUID：他始终以serialVersionUID = 1L开头，然后在对该类进行一些重大更改时将其递增1。
JDK类似乎总是使用更复杂的生成
serialVersionUIDs，如java.lang.String类：
private static final long serialVersionUID = -6849794470754667710L;
现在，我的同事询问这种serialVersionUID与简单的serialVersionUID（例如1L，2L，3L ......）相比的优势？
我们还搜索了SOF，但对给出的答案并不十分满意，例如在Why generate long serialVersionUID instead of a simple 1L?中。
在我看来，使用生成的ID的优势在于它不需要任何关于“老年人”的信息。类版本。但是当手动递增ID时，您必须知道到目前为止的最高值。这可能听起来微不足道（通过查看当前的serialVersionUID并将其增加1），但在更大的软件项目，更大的开发团队或分布式环境中可能会更复杂。
答案 0 :(得分：1)
使用生成的版本的优点是，如果它在没有serialVersionUID的情况下进行了扩展，它与该类的先前版本兼容。
话虽如此，你的同事增加它几乎肯定是错误的。 serialVersionUID只应在您接受该类已无可挽回地更改且您故意要引入序列化不兼容的位置进行更改。在本质上发生这种情况的时间很少，仅限于以不兼容的方式更改类的继承或成员字段类型的情况。如果您决定上课Serializable，那么您应该已经接受了制度，但不会发生这种情况。
答案 1 :(得分：-1)
这是一个有趣的问题，直截了当：我不知道。
SUID是公共API的一部分。 一旦您发布了在外部使用的API 你的控制，就像JDK一样，你无法改变这一点 数字不会破坏兼容性。
所以我看不出使用号码有什么好处 比如32432544354343L而不是1L。
但对于内部开发，我看到了一个小优势 以1L之类的数字开头：
假设我们有3个JMI客户端 - 服务器应用程序：
在api.jar中有一些商业类 歌曲，专辑，...客户端和服务器使用，其中一个 序列化的。
现在我们从其中一些类开始使用1L的SUID 在发布后，我们更改了一个内部格式 这些类中，我们将SUID增加到2L。
现在客户端和服务器组件都需要包含 新的api.jar。 如果我们犯了一个错误，忘记更新客户端或 使用新api.jar依赖的服务器会出现异常 在反序列化期间。异常中的消息将包括 不兼容的SUID。
所以这里的数字1L和2L在消息中。 2L＆gt; 1L， 因此我们知道该组件使用旧的api.jar。 使用IDE生成的数字，如123434534553L和654642646363L，我们不会 知道哪个组件使用旧的api.jar。
但另一方面甚至是新的JDK类 LocalDate使用的数字如123434534553L而不是 一个更简单的。 在apache commons-lang中似乎有混合， 例如FastDateParser.java使用简单的3L。
...奇怪