blocks|key|4255751|text|它会根据类的结构自动生成。如果结构改变，则重新生成id+(根据serialization+specification，它是类的散列)。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|4255752|所以你最好定义一个显式的serialVersionUID。|style|CODE|4255753|entityMap|0|LINK|mutability|MUTABLE|url|http://download.oracle.com/javase/1.3/docs/guide/serialization/spec/version.doc5.html^0|V|R|0|0|C|G|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@$A|U|B|V|F|G]]|9|@]|C|$]]|$1|H|3|-4|5|6|7|W|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

It is automatically generated, based on the structure of the class. If the structure changes, the id is regenerated (according to the <a href="http://download.oracle.com/javase/1.3/docs/guide/serialization/spec/version.doc5.html" rel="nofollow noreferrer">serialization specification</a> it is a hashof the class).

So you'd better define an explicit <code>serialVersionUID</code>.

blocks|key|942866|text|如果您使用Eclipse作为您的集成开发环境，您可以右键单击有关缺少serialVersionUID的警告，您将看到两个选项：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|942867|1)定义Eclipse默认值，其值为1L；或者|942868|2)定义一个随机生成的长值|942869|如果您关心序列化对象的版本控制，则需要在每次修改类时手动重新生成一个新值。Serializable接口的Javadoc告诉我们如果根本不声明serialVersionUID会发生什么：|942870|942871|如果可序列化类没有显式声明serialVersionUID，则序列化运行时将根据该类的各个方面计算该类的默认serialVersionUID值，如Java对象序列化规范中所述。但是，强烈建议所有可序列化的类显式声明serialVersionUID值，因为默认的serialVersionUID计算对类细节高度敏感，这些细节可能因编译器实现而异，因此在反序列化过程中可能会导致意外的InvalidClassExceptions。因此，为了在不同的java编译器实现中保证一致的serialVersionUID值，可序列化的类必须声明显式的serialVersionUID值。|blockquote|942872|942873|942874|在实践中，我发现即使在两台或更多的机器上(例如，从Subversion中检出)开始使用相同的源代码，并且类中的serialVersionUID未在类中定义，编译代码时，类中编译器生成的值在每台机器上也是不同的。这可能会在开发过程中导致令人困惑的错误。|942875|如果您确信不会出现与新版本的类不同步的陈旧序列化对象的情况(或者两个JVM互相发送不同步的序列化对象，可能是通过网络或套接字连接)，那么只需将serialVersionUID的值设置为1L，并永远保持该值不变。|942876|http://download-llnw.oracle.com/javase/6/docs/api/java/io/Serializable.html|offset|length|942877|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|0|0|0|0|0|0|0|0|23|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|14|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|15|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|I|3|J|5|K|7|17|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|18|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|19|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1A|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1B|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1C|8|@]|9|@$T|1D|U|1E|1|1F]]|A|$]]|$1|V|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]]|W|$X|$5|Y|Z|10|A|$11|S]]]]

If you're using Eclipse as your IDE, you can right-click on the warning about the missing serialVersionUID and you'll get two options:

1) Define the Eclipse default, which has the value 1L; or 
2) Define a randomly generated long value

If you care about versioning of serialized objects, you'll need to manually regenerate a new value each time you modify the class. The Javadoc for the Serializable interface has this to say about what happens if you don't declare a serialVersionUID at all:

<blockquote>
 If a serializable class does not explicitly declare a serialVersionUID, then the serialization runtime will calculate a default serialVersionUID value for that class based on various aspects of the class, as described in the Java(TM) Object Serialization Specification. However, it is strongly recommended that all serializable classes explicitly declare serialVersionUID values, since the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations, and can thus result in unexpected InvalidClassExceptions during deserialization. Therefore, to guarantee a consistent serialVersionUID value across different java compiler implementations, a serializable class must declare an explicit serialVersionUID value.
</blockquote>

In practice, I've found that even if you start with identical source code on two or more machines (checked out of Subversion, for example) where serialVersionUID was undefined in a class, the compiler-generated value in the class is different on each machine when the code is compiled. This can cause confusing errors during development.

If you are sure that you'll never have a situation where you have stale serialized objects that are out-of-sync with a newer version of the class (or two JVMs sending out-of-sync serialized objects to each other, perhaps across a network or socket connection) then just set a value of 1L for serialVersionUID and leave it that way forever.

<a href="http://download-llnw.oracle.com/javase/6/docs/api/java/io/Serializable.html" rel="nofollow noreferrer">http://download-llnw.oracle.com/javase/6/docs/api/java/io/Serializable.html</a>

blocks|key|940858|text|serialversionuid不会自动生成，因为它很危险。当设置了serialversionuid时，这意味着一个类的两个版本在序列化方面是兼容的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|940859|假设您有一个名为Foo的类，并且它没有序列版本and+(缺省值)，并且您将Foo的一个实例序列化为一个文件。稍后，将一些新成员添加到Foo类中。如果您试图反序列化文件中的Foo对象，您将得到一个序列化失败，指出这些对象不兼容。它们是不兼容的，这是你想要的，也是默认的。它们是不兼容的，因为Foo类中的新成员不能从Foo的旧序列化实例初始化。|940860|现在，您可能会说，“我不在乎，在我的应用程序中，这些字段未初始化是可以接受的”。如果确实如此，您可以将新的Foo类的serialversionuid设置为与旧的Foo类相同。这将告诉Java对象在可序列化方面是兼容的，并且当您将旧的Foo实例反序列化为新的Foo类时，Java不会报错(但新字段仍未初始化)。|940861|如果您是第一次创建新类，并且设置了序列版本and，则输入的是合同。该约定是，“对于这个类的所有未来版本，我将保证它们在状态和序列化方面是兼容的”。|940862|如果您更改了一个类，并且明确希望禁止对旧版本进行反序列化，则可以将serialversionuid更改为新值。如果试图将旧对象反序列化为新的类实例，这将导致抛出异常。|940863|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

serialversionuid is not automatically generated because it is dangerous. When serialversionuid is set, it implies that two versions of a class are compatible with respect to serialization.

Imagine you have a class called Foo, and it has no serialversionuid (the default), and you serialize an instance of Foo to a file. Later, you add some new members to the Foo class. If you try to deserialize the Foo object from the file, you will get a serialization failure stating that the objects are incompatible. They are incompatible, this is what you want and is the default. They are incompatible because new members in the Foo class cannot be initialized from the old serialized instance of Foo.

Now, you might say, "I don't care, in my application it is acceptable for those fields to be uninitialized". If that really is the case, you can set the serialversionuid of the new Foo class to be the same as the old Foo class. This will tell Java that the objects are compatible with respect to serializablity, and Java will not complain when you deserialize the old Foo instance into the new Foo class (but the new fields will still be uninitialized).

If you are creating a new class for the first time, and you set the serialversionuid, you are entering a contract. That contract is, "For all future versions of this class with the same serialversionuid, I will guarantee they are compatible with respect to state and serialization".

If you change a class, and you explicitly want to disallow deserialization of old versions, you can change the serialversionuid to a new value. This will cause an exception to be thrown if an old object is attempted to be deserialized into a new class instance.

Why isn't the <code>serialVersionUID</code> automatically generated? I was running into an issue on an application server where apparently an old class was being cached.

Why isn't the serialVersionUID automatically generated?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

为什么不自动生成serialVersionUID？我在应用服务器上遇到了一个问题，很明显，缓存的是一个旧的类。

问为什么不自动生成serialVersionUID？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么不自动生成serialVersionUID？EN