什么是serialVersionUID，为什么要使用它？

SerialVersionUID是每个类的唯一标识符，JVM使用它来比较类的版本，以确保在序列化期间使用的相同类在反序列化期间加载。

指定一个可以提供更多控制，但如果不指定，JVM会生成一个。不同编译器生成的值可能不同。此外，有时您只是出于某种原因想要禁止旧序列化对象的反序列化[向后不兼容]，在这种情况下，您只需更改serialVersionUID。

Serializable的javadocs表示：

默认的serialVersionUID计算对类高度敏感详细信息可能因编译器实现而异因此，在反序列化。

因此，您必须声明serialVersionUID，因为它给了我们更多的控制权。

这篇文章在这个话题上有一些好的观点。

为什么在Java中的Serializable类中使用SerialVersionUID？

在序列化期间，Java运行时为类创建一个版本号，以便以后可以对其进行反序列化。此版本号在Java中称为SerialVersionUID。

SerialVersionUID用于序列化数据的版本。只有当类的SerialVersionUID与序列化实例匹配时，才能对其进行反序列化。当我们不在类中声明SerialVersionUID时，Java运行时会为我们生成它，但不建议这样做。建议将SerialVersionUID声明为私有静态最终长变量，以避免默认机制。

当您通过实现标记接口java.io.Serializable将类声明为Serializable时，如果您没有使用Externalizable接口自定义进程，java运行时将该类的实例通过默认Serialization机制持久化到磁盘中。

另请参阅为什么在Java中的Serializable类中使用SerialVersionUID

每次序列化对象时，对象都会标记对象类的版本ID号。此ID称为serialVersionUID，它是根据有关类结构的信息计算的。假设您创建了一个Employee类，它的版本id为#333（由JVM分配），现在当您将序列化该类的对象（假设Employees对象）时，JVM将为其分配UID为#333。

考虑一种情况——将来您需要编辑或更改类，在这种情况下，当您修改它时，JVM将为它分配一个新的UID（假设#444）。现在，当您尝试反序列化雇员对象时，JVM会将序列化对象（雇员对象）的版本ID（#333）与类的版本ID进行比较，即#444（自更改以来）。相比之下，JVM将发现两个版本UID不同，因此反序列化将失败。因此，如果每个类的serialVersionID由程序员自己定义。即使类在未来演变，它也将是相同的，因此JVM将始终发现类与序列化对象兼容，即使类已更改。有关更多信息，请参阅HEAD FIRST JAVA的第14章。

java.io.Serializable的文档可能与您将得到的解释一样好：

序列化运行时与每个可序列化类关联一个版本号，称为serialVersionUID，该版本号在反序列化期间用于验证序列化对象的发送方和接收方是否已为该对象加载了与序列化兼容的类。如果接收方为对象加载的类具有与对应发送方类不同的serialVersionUID，则反序列化将导致InvalidClassException。可序列化类可以通过声明一个名为serialVersionUID的字段来显式声明自己的serialVersionUID，该字段必须是静态的、final的和long类型：

ANY-ACCESS-MODIFIER静态最终长序列版本UID=42L；

如果可序列化类未显式声明serialVersionUID，则序列化运行时将根据该类的各个方面计算该类的默认serialVersionID值，如Java（TM）对象序列化规范中所述。但是，强烈建议所有可序列化类显式声明serialVersionUID值，因为默认的serialVersionUID计算对可能因编译器实现而异的类细节高度敏感，因此在反序列化期间可能会导致意外的InvalidClassExceptions。因此，为了保证不同java编译器实现之间的serialVersionUID值一致，可序列化类必须声明显式的serialVersion UID值。还强烈建议显式serialVersionUID声明在可能的情况下使用私有修饰符，因为此类声明仅适用于立即声明的类-serialVersionUID字段作为继承成员不有用。

要理解字段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。