serialVersionUID 不是被 static 变量修饰了吗？为什么还会被“序列化”？这个问题的回答是有问题的

[abekthink]

原文回答是：static 修饰的变量是静态变量，位于方法区，本身是不会被序列化的。 static 变量是属于类的而不是对象。你反序列之后，static 变量的值就像是默认赋予给了对象一样，看着就像是 static 变量被序列化，实际只是假象罢了。

这个回答本身是有问题的，如果是拿默认值序列化的话，那序列化的二进制字节流的serialVersionUID就应该是0，那对于接收方在反序列化的时候就无法再依据serialVersionUID是否一致来去判别了。
所以正确的答案是：static 修饰的变量是静态变量，位于方法区，本身是不会被序列化的。但是，serialVersionUID的序列化做了特殊处理，在序列化时，会将serialVersionUID序列化到二进制字节流中；在反序列化时，也会解析它并做一致性判断。

证明：拿ObjectOutputStream和ObjectInputStream的实现来看，在ObjectOutputStream.writeObject()时，底层调用了ObjectStreamClass.writeNonProxy()方法，其中包含了将serialVersionUID写入输出流；在ObjectInputStream.readObject()时，底层调用了ObjectStreamClass.readNonProxy()和ObjectStreamClass.initNonProxy()方法，前者用来从输入流里读取serialVersionUID，后者用来比对Class里的serialVersionUID和输入流里的serialVersionUID是否一致。

原文：https://github.com/Snailclimb/JavaGuide/blob/main/docs/java/basis/serialization.md#jdk-%E8%87%AA%E5%B8%A6%E7%9A%84%E5%BA%8F%E5%88%97%E5%8C%96%E6%96%B9%E5%BC%8F

[Snailclimb]

原文回答是：static 修饰的变量是静态变量，位于方法区，本身是不会被序列化的。 static 变量是属于类的而不是对象。你反序列之后，static 变量的值就像是默认赋予给了对象一样，看着就像是 static 变量被序列化，实际只是假象罢了。

这个回答本身是有问题的，如果是拿默认值序列化的话，那序列化的二进制字节流的serialVersionUID就应该是0，那对于接收方在反序列化的时候就无法再依据serialVersionUID是否一致来去判别了。 所以正确的答案是：static 修饰的变量是静态变量，位于方法区，本身是不会被序列化的。但是，serialVersionUID的序列化做了特殊处理，在序列化时，会将serialVersionUID序列化到二进制字节流中；在反序列化时，也会解析它并做一致性判断。

证明：拿ObjectOutputStream和ObjectInputStream的实现来看，在ObjectOutputStream.writeObject()时，底层调用了ObjectStreamClass.writeNonProxy()方法，其中包含了将serialVersionUID写入输出流；在ObjectInputStream.readObject()时，底层调用了ObjectStreamClass.readNonProxy()和ObjectStreamClass.initNonProxy()方法，前者用来从输入流里读取serialVersionUID，后者用来比对Class里的serialVersionUID和输入流里的serialVersionUID是否一致。

原文：https://github.com/Snailclimb/JavaGuide/blob/main/docs/java/basis/serialization.md#jdk-%E8%87%AA%E5%B8%A6%E7%9A%84%E5%BA%8F%E5%88%97%E5%8C%96%E6%96%B9%E5%BC%8F

感谢修正！

[SkyGra]

静态变量在jdk 1.7开始，就移到了堆中，这里怎么又说是在方法区中呢

[Snailclimb]

静态变量在jdk 1.7开始，就移到了堆中，这里怎么又说是在方法区中呢

没注意到，JDK1.7 字符串常量池和静态变量从永久代移动了 Java 堆中。

[Snailclimb]

已修改：

static 修饰的变量是静态变量，属于类而非类的实例，本身是不会被序列化的。然而，serialVersionUID 是一个特例，serialVersionUID 的序列化做了特殊处理。当一个对象被序列化时，serialVersionUID 会被写入到序列化的二进制流中；在反序列化时，也会解析它并做一致性判断，以此来验证序列化对象的版本一致性。如果两者不匹配，反序列化过程将抛出 InvalidClassException，因为这通常意味着序列化的类的定义已经发生了更改，可能不再兼容。

[StoneStone11]

这里是不是有点上下矛盾了

[DrinkFish0]

先说结论：serialVersionUID 的值不会被序列化到流中，但序列化后的流中会记录它的版本信息。
验证方法：
定义一个类显示指定 serialVersionUID 的值进行序列化，然后修改 serialVersionUID 的值，再进行反序列化，此时会抛 java.io.InvalidClassException 异常，这证明 serialVersionUID 的版本信息被隐式记录在流中了，但是通过查看序列化后的二进制文件，并没有存储 serialVersionUID 的值。

[Snailclimb]

serialVersionUID

这里是不是有点上下矛盾了

这样描述会不会好一点呢：

通常情况下，static 变量是属于类的，不属于任何单个对象实例，所以它们本身不会被包含在对象序列化的数据流里。序列化保存的是对象的状态（也就是实例变量的值）。然而，serialVersionUID 是一个特例，serialVersionUID 的序列化做了特殊处理。关键在于，serialVersionUID 不是作为对象状态的一部分被序列化的，而是被序列化机制本身用作一个特殊的“指纹”或“版本号”。

当一个对象被序列化时，serialVersionUID 会被写入到序列化的二进制流中（像是在保存一个版本号，而不是保存 static 变量本身的状态）；在反序列化时，也会解析它并做一致性判断，以此来验证序列化对象的版本一致性。如果两者不匹配，反序列化过程将抛出 InvalidClassException，因为这通常意味着序列化的类的定义已经发生了更改，可能不再兼容。