1700439262
1700439263
现在，Person类的代码需要修改，initName的返回值也改变了，代码如下：
1700439264
1700439265
public class Person implements Serializable{
1700439266
1700439267
private static final long serialVersionUID=91282334L；
1700439268
1700439269
//通过方法返回值为final变量赋值
1700439270
1700439271
public final String name=initName（）；
1700439272
1700439273
//初始化方法名
1700439274
1700439275
public String initName（）{
1700439276
1700439277
return”德天使”；
1700439278
1700439279
}
1700439280
1700439281
}
1700439282
1700439283
上段代码仅仅修改了initName的返回值（Person类为V2.0版本），也就是说通过new生成的Person对象的final变量值都是“德天使”。那么我们把之前存储在磁盘上的实例加载上来，name值会是什么呢？
1700439284
1700439285
结果是：混世魔王。很诧异，上一建议说过final变量会被重新赋值，但是这个例子又没有重新赋值，为什么？
1700439286
1700439287
上个建议所说final会被重新赋值，其中的“值”指的是简单对象。简单对象包括：8个基本类型，以及数组、字符串（字符串情况很复杂，不通过new关键字生成String对象的情况下，final变量的赋值与基本类型相同），但是不能方法赋值。
1700439288
1700439289
其中的原理是这样的，保存到磁盘上（或网络传输）的对象文件包括两部分：
1700439290
1700439291
（1）类描述信息
1700439292
1700439293
包括包路径、继承关系、访问权限、变量描述、变量访问权限、方法签名、返回值，以及变量的关联类信息。要注意的一点是，它并不是class文件的翻版，它不记录方法、构造函数、static变量等的具体实现。之所以类描述会被保存，很简单，是因为能去也能回嘛，这保证反序列化的健壮运行。
1700439294
1700439295
（2）非瞬态（transient关键字）和非静态（static关键字）的实例变量值
1700439296
1700439297
注意，这里的值如果是一个基本类型，好说，就是一个简单值保存下来；如果是复杂对象，也简单，连该对象和关联类信息一起保存，并且持续递归下去（关联类也必须实现Serializable接口，否则会出现序列化异常），也就是说递归到最后，其实还是基本数据类型的保存。
1700439298
1700439299
正是因为这两点原因，一个持久化后的对象文件会比一个class类文件大很多，有兴趣的读者可以自己写个Hello word程序检验一下，其体积确实膨胀了不少。
1700439300
1700439301
总结一下，反序列化时final变量在以下情况下不会被重新赋值：
1700439302
1700439303
通过构造函数为final变量赋值。
1700439304
1700439305
通过方法返回值为final变量赋值。
1700439306
1700439307
final修饰的属性不是基本类型。
1700439308
1700439309
1700439310
1700439311
[
上一页 ]
[ :1.700439262e+09 ]
[
下一页 ]