1700439180
1700439181
SerializationUtils.writeObject（new Person（））；
1700439182
1700439183
}
1700439184
1700439185
}
1700439186
1700439187
Person的实例对象保存到了磁盘上，它是一个贫血对象（承载业务属性定义，但不包含其行为定义），我们做一个简单的模拟，修改一下name值代表变更，要注意的是serialVersionUID保持不变，修改后的代码如下：
1700439188
1700439189
public class Person implements Serializable{
1700439190
1700439191
private static final long serialVersionUID=91282334L；
1700439192
1700439193
//不变量初始不赋值
1700439194
1700439195
public final String name；
1700439196
1700439197
//构造函数为不变量赋值
1700439198
1700439199
public Person（）{
1700439200
1700439201
name=“德天使”；
1700439202
1700439203
}
1700439204
1700439205
}
1700439206
1700439207
此时Person类的版本是V2.0，但serialVersionUID没有改变，仍然可以反序列化，其代码如下：
1700439208
1700439209
public class Deserialize{
1700439210
1700439211
public static void main（String[]args）{
1700439212
1700439213
//反序列化
1700439214
1700439215
Person p=（Person）SerializationUtils.readObject（）；
1700439216
1700439217
System.out.println（p.name）；
1700439218
1700439219
}
1700439220
1700439221
}
1700439222
1700439223
现在问题来了：打印的结果是什么？是混世魔王还是德天使？
1700439224
1700439225
答案即将揭晓，答案是：混世魔王。
1700439226
1700439227
final类型的变量不是会重新计算吗？答案应该是“德天使”才对啊，为什么会是“混世魔王”？这是因为这里触及了反序列化的另一个规则：反序列化时构造函数不会执行。
1700439228
1700439229
反序列化的执行过程是这样的：JVM从数据流中获取一个Object对象，然后根据数据流中的类文件描述信息（在序列化时，保存到磁盘的对象文件中包含了类描述信息，注意是类描述信息，不是类）查看，发现是final变量，需要重新计算，于是引用Person类中的name值，而此时JVM又发现name竟然没有赋值，不能引用，于是它很“聪明”地不再初始化，保持原值状态，所以结果就是“混世魔王”了。
[
上一页 ]
[ :1.70043918e+09 ]
[
下一页 ]