我通常在一个上下文中使用serialVersionUID：当我知道它将离开JavaVM的上下文时。

当我为我的应用程序使用ObjectInputStream和ObjectOutputStream时，或者如果我知道我使用的库/框架将使用它时，我会知道这一点。serialVersionID确保不同版本或供应商的不同Java VM能够正确互操作，或者如果它在VM外部存储和检索（例如HttpSession），会话数据即使在应用服务器。

对于所有其他情况，我使用

@SuppressWarnings("serial")

因为大多数时候默认的serialVersionUID就足够了。这包括异常、HttpServlet。

如果您永远不需要将对象序列化到字节数组并发送/存储它们，那么您就不必担心。如果需要，那么您必须考虑serialVersionUID，因为对象的反序列化程序会将其与其类加载器所具有的对象版本相匹配。在Java语言规范中了解更多有关它的信息。

我不能错过这个机会，插上乔什·布洛克（Josh Bloch）的书《有效的Java》（第二版）。第10章是关于Java序列化的不可或缺的资源。

根据Josh的说法，自动生成的UID是基于类名、实现的接口以及所有公共和受保护的成员生成的。以任何方式更改任何这些都将更改serialVersionUID。因此，只有当您确定不会有多个版本的类被串行化（跨进程或稍后从存储中检索）时，才不需要使用它们。

如果您现在忽略它们，然后发现需要以某种方式更改类，但保持与旧版本类的兼容性，则可以使用JDK工具serialver在旧类上生成serialVersionUID，并在新类上显式设置。（根据您的更改，您可能还需要通过添加writeObject和readObject方法来实现自定义序列化-请参阅Serializable javadoc或上述第10章。）

最初的问题是问“为什么它很重要”和“示例”，这个串行版本ID在哪里有用。我找到了一个。

假设您创建了一个Car类，将其实例化，并将其写入对象流。扁平的汽车对象在文件系统中放置一段时间。同时，如果通过添加新字段来修改Car类。稍后，当您尝试读取（即反序列化）扁平化的Car对象时，会得到java.io.InvalidClassException——因为所有可序列化的类都会自动给定一个唯一的标识符。当类的标识符不等于展平对象的标识符时，将引发此异常。如果你真的想一想，由于添加了新字段，就会引发异常。通过声明显式的serialVersionUID来控制版本控制，可以避免引发此异常。显式声明serialVersionUID（因为不必计算）也有一个小的性能优势。因此，最好在创建Serializable类后立即将自己的serialVersionUID添加到它们中，如下所示：

public class Car {
    static final long serialVersionUID = 1L; //assign a long value
}

要理解字段serialVersionUID的重要性，应该了解序列化/反序列化的工作原理。

当序列化一个Serializable类对象时，Java Runtime将一个序列版本号（称为serialVersionUID）与这个序列化对象相关联。在反序列化此序列化对象时，Java Runtime将序列化对象的serialVersionUID与类的serialVersion UID匹配。如果两者都相等，则只有它继续执行进一步的反序列化过程，否则抛出InvalidClassException。

因此，我们得出结论，要使序列化/反序列化过程成功，序列化对象的serialVersionUID必须与类的serialVersion UID等效。如果程序员在程序中显式指定serialVersionUID值，那么无论序列化和反序列化平台如何，相同的值都将与序列化对象和类相关联（例如，可以使用sun或MS JVM在类似windows的平台上进行序列化，而反序列化可以使用Zing JVM在不同的平台Linux上进行）。

但是，如果程序员未指定serialVersionUID，则在对任何对象进行Serialization\DeSerialization时，Java运行时会使用自己的算法来计算它。这种serialVersionUID计算算法因JRE而异。对象序列化的环境也可能使用一个JRE（例如：SUN JVM），而取消序列化的环境则使用LinuxJvm（zing）。在这种情况下，与序列化对象关联的serialVersionUID将不同于在取消序列化环境中计算的类的serialVersion UID。反过来，反序列化将不会成功。所以为了避免这种情况/问题，程序员必须始终指定Serializable类的serialVersionUID。

我通常在一个上下文中使用serialVersionUID：当我知道它将离开JavaVM的上下文时。

当我为我的应用程序使用ObjectInputStream和ObjectOutputStream时，或者如果我知道我使用的库/框架将使用它时，我会知道这一点。serialVersionID确保不同版本或供应商的不同Java VM能够正确互操作，或者如果它在VM外部存储和检索（例如HttpSession），会话数据即使在应用服务器。

对于所有其他情况，我使用

@SuppressWarnings("serial")

因为大多数时候默认的serialVersionUID就足够了。这包括异常、HttpServlet。