避免用序列化类在构造函数中为不变量赋值

避免用序列化类在构造函数中为不变量赋值

我们知道带有final标识的属性是不变量，也就是说只能赋值一次，不能重复赋值，但是在序列化类中就有点复杂了，比如有这样一个类：

public class Person implements Serializable{      
     private static final long serialVersionUID = 71282334L;  
     //不变量  
     public  final String name="混世魔王";  
} 

这个Person类（此时V1.0版本）被序列化，然后存储在磁盘上，在反序列化时name属性会重新计算其值（这与static变量不同，static变量压根就没有保存到数据流中），比如name属性修改成了“德天使”（版本升级为V2.0），那么反序列化对象的name值就是“德天使”。保持新旧对象的final变量相同，有利于代码业务逻辑统一，这是序列化的基本规则之一，也就是说，如果final属性是一个直接量，在反序列化时就会重新计算。对这基本规则不多说，我们要说的是final变量另外一种赋值方式：通过构造函数赋值。代码如下：

public class Person implements Serializable{      
     private static final long serialVersionUID = 91282334L;  
     //不变量初始不赋值  
     public  final String name;  
     //构造函数为不变量赋值  
     public Person(){  
         name="混世魔王";  
    }  
} 

这也是我们常用的一种赋值方式，可以把这个Person类定义为版本V1.0，然后进行序列化，看看有什么问题没有，序列化的代码如下所示：

public class Serialize {  
    public static void main(String[] args) {  
        //序列化以持久保存  
        SerializationUtils.writeObject(new Person());  
    }  
} 

Person的实例对象保存到了磁盘上，它是一个贫血对象（承载业务属性定义，但不包含其行为定义），我们做一个简单的模拟，修改一下name值代表变更，要注意的是serialVersionUID保持不变，修改后的代码如下：

public class Person implements Serializable{      
     private static final long serialVersionUID = 91282334L;  
     //不变量初始不赋值  
     public  final String name;  
     //构造函数为不变量赋值  
     public Person(){  
         name="德天使";  
     }  
} 

此时Person类的版本是V2.0，但serialVersionUID没有改变，仍然可以反序列化，其代码如下：

public class Deserialize {  
     public static void main(String[] args) {  
           //反序列化  
           Person p = (Person)SerializationUtils.readObject();        
           System.out.println(p.name);  
    }  
} 

现在问题来了：打印的结果是什么？是混世魔王还是德天使？

答案即将揭晓，答案是：混世魔王。

final类型的变量不是会重新计算吗？答案应该是“德天使”才对啊，为什么会是“混世魔王”？这是因为这里触及了反序列化的另一个规则：反序列化时构造函数不会执行。

反序列化的执行过程是这样的：JVM从数据流中获取一个Object对象，然后根据数据流中的类文件描述信息（在序列化时，保存到磁盘的对象文件中包含了类描述信息，注意是类描述信息，不是类）查看，发现是final变量，需要重新计算，于是引用Person类中的name值，而此时JVM又发现name竟然没有赋值，不能引用，于是它很“聪明”地不再初始化，保持原值状态，所以结果就是“混世魔王”了。

读者不要以为这样的情况很少发生，如果使用Java开发过桌面应用，特别是参与过对性能要求较高的项目（比如交易类项目），那么很容易遇到这样的问题。比如一个C/S结构的在线外汇交易系统，要求提供24小时的联机服务，如果在升级的类中有一个final变量是构造函数赋值的，而且新旧版本还发生了变化，则在应用请求热切的过程中（非常短暂，可能只有30秒），很可能就会出现反序列化生成的final变量值与新产生的实例值不相同的情况，于是业务异常就产生了，情况严重的话甚至会影响交易数据，那可是天大的事故了。

注意　在序列化类中，不使用构造函数为final变量赋值。

为final变量赋值还有一种方式：通过方法赋值，即直接在声明时通过方法返回值赋值。还是以Person类为例来说明，代码如下：

public class Person implements Serializable{      
     private static final long serialVersionUID = 91282334L;  
     //通过方法返回值为final变量赋值  
     public  final String name=initName();    
     //初始化方法名  
     public String initName(){  
         return "混世魔王";  
     }  
} 

name属性是通过initName方法的返回值赋值的，这在复杂类中经常用到，这比使用构造函数赋值更简洁、易修改，那么如此用法在序列化时会不会有问题呢？我们一起来看看。Person类写好了（定义为V1.0版本），先把它序列化，存储到本地文件，其代码与上一建议的Serialize类相同，不再赘述。

现在，Person类的代码需要修改，initName的返回值也改变了，代码如下：

public class Person implements Serializable{      
     private static final long serialVersionUID = 91282334L;  
     //通过方法返回值为final变量赋值  
     public  final String name=initName();    
     //初始化方法名  
     public String initName(){  
           return "德天使";  
     }  
} 

上段代码仅仅修改了initName的返回值（Person类为V2.0版本），也就是说通过new生成的Person对象的 final变量值都是“德天使”。那么我们把之前存储在磁盘上的实例加载上来，name值会是什么呢？

结果是：混世魔王。很诧异，上一建议说过final变量会被重新赋值，但是这个例子又没有重新赋值，为什么？

上个建议所说final会被重新赋值，其中的“值”指的是简单对象。简单对象包括：8个基本类型，以及数组、字符串（字符串情况很复杂，不通过new关键字生成String对象的情况下，final变量的赋值与基本类型相同），但是不能方法赋值。

其中的原理是这样的，保存到磁盘上（或网络传输）的对象文件包括两部分：

（1）类描述信息

包括包路径、继承关系、访问权限、变量描述、变量访问权限、方法签名、返回值，以及变量的关联类信息。要注意的一点是，它并不是class文件的翻版，它不记录方法、构造函数、static变量等的具体实现。之所以类描述会被保存，很简单，是因为能去也能回嘛，这保证反序列化的健壮运行。

（2）非瞬态（transient关键字）和非静态（static关键字）的实例变量值

注意，这里的值如果是一个基本类型，好说，就是一个简单值保存下来；如果是复杂对象，也简单，连该对象和关联类信息一起保存，并且持续递归下去（关联类也必须实现Serializable接口，否则会出现序列化异常），也就是说递归到最后，其实还是基本数据类型的保存。

正是因为这两点原因，一个持久化后的对象文件会比一个class类文件大很多，有兴趣的读者可以自己写个Hello word程序检验一下，其体积确实膨胀了不少。

总结一下，反序列化时final变量在以下情况下不会被重新赋值：

通过构造函数为final变量赋值。

通过方法返回值为final变量赋值。

final修饰的属性不是基本类型。