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竟然没有赋值，不能引用，于是它很“聪明”地不再初始化，保持原值状态，所以结果就是“混世魔王”了。
1700439230
1700439231
读者不要以为这样的情况很少发生，如果使用Java开发过桌面应用，特别是参与过对性能要求较高的项目（比如交易类项目），那么很容易遇到这样的问题。比如一个C/S结构的在线外汇交易系统，要求提供24小时的联机服务，如果在升级的类中有一个final变量是构造函数赋值的，而且新旧版本还发生了变化，则在应用请求热切的过程中（非常短暂，可能只有30秒），很可能就会出现反序列化生成的final变量值与新产生的实例值不相同的情况，于是业务异常就产生了，情况严重的话甚至会影响交易数据，那可是天大的事故了。
1700439232
1700439233
注意 在序列化类中，不使用构造函数为final变量赋值。
1700439234
1700439235
1700439236
1700439237
1700439239
编写高质量代码：改善Java程序的151个建议 建议13：避免为final变量复杂赋值
1700439240
1700439241
为final变量赋值还有一种方式：通过方法赋值，即直接在声明时通过方法返回值赋值。还是以Person类为例来说明，代码如下：
1700439242
1700439243
public class Person implements Serializable{
1700439244
1700439245
private static final long serialVersionUID=91282334L；
1700439246
1700439247
//通过方法返回值为final变量赋值
1700439248
1700439249
public fnal String name=initName（）；
1700439250
1700439251
//初始化方法名
1700439252
1700439253
public String initName（）{
1700439254
1700439255
return”混世魔王”；
1700439256
1700439257
}
1700439258
1700439259
}
1700439260
1700439261
name属性是通过initName方法的返回值赋值的，这在复杂类中经常用到，这比使用构造函数赋值更简洁、易修改，那么如此用法在序列化时会不会有问题呢？我们一起来看看。Person类写好了（定义为V1.0版本），先把它序列化，存储到本地文件，其代码与上一建议的Serialize类相同，不再赘述。
[
上一页 ]
[ :1.700439212e+09 ]
[
下一页 ]