你所不知道的Java序列化

我们都知道，Java序列化可以让我们记录下运行时的对象状态(对象实例域的值)，也就是我们经常说的对象持久化 。这个过程其实是非常复杂的，这里我们就好好理解一下Java的对象序列化。

 

1、 首先我们要搞清楚，Java对象序列化是将 对象的实例域数据( 包括private私有域) 进行持久化存储。而并非是将整个对象所属的类信息进行存储。 其实了解JVM的话，我们就能明白这一点了。实际上堆中所存储的对象包含了实例域数据值以及指向类信息的地址，而对象所属的类信息却存放在方法区中。当我们要对持久层数据反序列化成对象的时候，也就只需要将实例域数据值存放在新创建的对象中即可。

 

2、 我们都知道凡要序列化的类都必须实现Serializable接口。 但是不是所有类都可以序列化呢？当然不是这样，想想看序列化可以让我们轻而易举的接触到对象的私有数据域，这是多么危险的漏洞呀！总结一下，JDK中有四种类型的类对象是绝对不能序列化的 。

     (1) 太依赖于底层实现的类(too closely tied to native code)。比如java.util.zip.Deflater。 

     (2) 对象的状态依赖于虚拟机内部和不停变化的运行时环境。比如java.lang.Thread, java.io.InputStream
     (3) 涉及到潜在的安全性问题。比如：java.lang.SecurityManager, java.security.MessageDigest
     (4) 全是静态域的类，没有对象实例数据。要知道静态域本身也是存储在方法区中的。

 

3、 自定义的类只要实现了Serializable接口，是不是都可以序列化呢？ 当然也不是这样，看看下面的例子：

Java代码  

1. class Employee implements Serializable{  
2.          private ZipFile zf=null;  
3.          Employee(ZipFile zf){  
4.                 this.zf=zf;  
5.          }   
6. }  
7.   
8. ObjectOutputStream oout=  
9. new ObjectOutputStream(new FileInputStream(new File("aaa.txt")));  
10. oout.writeObject(new Employee(new ZipFile("c://.."));  

     我们会发现运行之后抛出java.io.NotSerializableException : java.util.zip.ZipFile 。很明显，如果要对Employee对象序列化，就必须对其数据域ZipFile对象也进行序列化，而这个类在JDK中是不可序列化的。因此，包含了不可序列化的对象域的对象也是不能序列化的。 实际上，这也并非不可能，我们在下面第6点会谈到。

 

4、 可序列化的类成功序列化之后，是不是一定可以反序列化呢？ (这里默认在同一环境下，而且类定义永远不会改变，即满足兼容性。在下面我们会讨论序列化的不兼容性)。答案是不一定哦！我们还是看一个列子：

Java代码  

1. //父类对象不能序列化  
2. class Employee{   
3.     private String name;  
4.     Employee(String n){  
5.         this.name=n;  
6.     }  
7.     public String getName(){  
8.         return this.name;  
9.     }  
10. }  
11. //子类对象可以序列化  
12. class Manager extends Employee implements Serializable{  
13.     private int id;  
14.     Manager(String name, int id){  
15.         super(name);  
16.         this.id=id;  
17.     }  
18. }  
19. //序列化与反序列化测试  
20. public static void main(String[] args) throws IOException, ClassNotFoundException{  
21.          File file=new File("E:/aaa.txt");  
22.     ObjectOutputStream oout=new ObjectOutputStream(new FileOutputStream(file));  
23.     oout.writeObject(new Manager("amao",123));  
24.     oout.close();  
25.     System.out.println("序列化成功");  
26.           
27.     ObjectInputStream oin=new ObjectInputStream(new FileInputStream(file));  
28.     Object o=oin.readObject();  
29.     oin.close();  
30.     System.out.println("反序列化成功:"+((Manager) o).getName());  
31. }  

        程序的运行结果是：打印出“序列化成功”之后抛出java.io.InvalidClassException: Manager; Manager; no valid constructor。 为什么会出现这种情况呢？很显然，序列化的时候只是将Manager类对象的数据域id写入了文件，但在反序列化的过程中，需要在堆中建立一个Manager新对象。我们都知道任何一个类对象的建立都首先需要调用父类的构造器对父类进行初始化，很可惜序列化文件中并没有父类Employee的name数据，那么此时调用Employee(String)构造器会因为没有数据而出现异常。既然没有数据，那么可不可以调用无参构造器呢？ 事实却是如此，如果有Employee()无参构造器的存在，将不会抛出异常，只是在执行打印的时候出现--- “反序列化成功：null”。

       总结一下：如果当前类的所有超类中有一个类即不能序列化，也没有无参构造器。那么当前类将不能反序列化。如果有无参构造器，那么此超类反序列化的数据域将会是null或者0，false等等。 

 

5、 序列化的兼容性问题！

     类定义很有可能在不停的人为更新(比如JDK1.1到JDK1.2中HashTable的改变)。那么以前序列化的旧类对象很可能不能再反序列化成为新类对象。这就是序列化的兼容性问题，严格意义上来说改变类中除static 和transient以外的所有部分都会造成兼容性问题。而JDK采用了一种stream unique identifier (SUID) 来识别兼容性。SUID是通过复杂的函数来计算的类名，接口名，方法和数据域的 一个64位 hash值。而这个值存储在类中的静态域内：

                               private static final long serialVersionUID = 3487495895819393L

只要稍微改动类的定义，这个类的SUID就会发生变化，我们通过下面的程序来看看：

Java代码  

1. //修改前的Employee  
2. class Employee implements Serializable{  
3.     private String name;  
4.     Employee(String n){  
5.         this.name=n;  
6.     }  
7.     public String getName(){  
8.         return this.name;  
9.     }  
10. }  
11. //测试，打印SUID=5135178525467874279L  
12. long serialVersionUID=ObjectStreamClass.lookup(Class.forName("Employee")).getSerialVersionUID();  
13. System.out.println(serialVersionUID);  
14.   
15. //修改后的Employee  
16. class Employee implements Serializable{  
17.     private String name1; //注意，这里略微改动一下数据域的名字  
18.     Employee(String n){  
19.         this.name1=n;  
20.     }  
21.     public String getName(){  
22.         return this.name1;  
23.     }  
24. }  
25. //测试，打印SUID=-2226350316230217613L  
26. long serialVersionUID=ObjectStreamClass.lookup(Class.forName("Employee")).getSerialVersionUID();  
27. System.out.println(serialVersionUID);  

      两次测试的SUID都不一样，不过你可以试试如果name域是static或transient声明的，那么改变这个域名是不会影响SUID的。

     很显然，JVM正是通过检测新旧类SUID的不同，来检测出序列化对象与反序列化对象的不兼容。抛出java.io.InvalidClassException: Employee; local class incompatible:

     很多时候，类定义的改变势在必行，但又不希望出现序列化的不兼容性。我们就可以通过在类中显示的定义serialVersionUID，并赋予一个明确的long值即可。这样会逃过JVM的默认兼容性检查。但是如果数据域名的改变会导致反序列化后，改变的数据域只能得到默认的null或者0或者false值。

 

6、 在上面第3点中谈到了一个不能成功序列化的Employee的列子，原因就是包含了一个不能序列化的ZipFile对象引用的数据域。但有时我们非常想将ZipFile所对应的本地文件路径进行序列化，是不是真的没有办法了呢？ 这里我们就将一个非常有用的应用。

      当我们需要用writeObject(Object)方法对某个类对象序列化的时候，会首先对这个类对象的所有超类按照继承层次从高到低来写出每个超类的数据域。谁能保证每个超类都实现了Serializable接口呢？ 其实，对于这些不能序列化的类，JVM会检查这些类是否有这样一个方法:

                  private void writeObject(ObjectOutputStream out)throws IOException 
      如果有，JVM会调用这个方法仍然对该类的数据域进行序列化。我们来看看JDK的ObjectOutputStream类中对这一部分的实现(我这里只列出了源码中的执行过程)：

Java代码  

1. //下面的方法从上到下进行调用  
2. writeObject(Object);   
3.   
4. //ObjectOutputStream的writeObject方法  
5. public final void writeObject(Object obj) throws IOException {   
6.         writeObject0(obj, false);  
7. }  
8.   
9. //ObjectOutputStream, 底层写入Object的实现  
10. private void writeObject0(Object obj, boolean unshared) {  
11.        if (obj instanceof Serializable) {  
12.         writeOrdinaryObject(obj, desc, unshared);  
13. }  
14.   
15. //ObjectOutputStream  
16. private void writeOrdinaryObject(Object obj, ObjectStreamClass desc,  boolean unshared) {  
17.        writeSerialData(obj, desc);  
18. }  
19.   
20. //ObjectOutputStream, 对超类到子类的每个可序列化的类，写出数据域  
21.  private void writeSerialData(Object obj, ObjectStreamClass desc)  throws IOException{  
22.          //如果类中有writeObject(ObjectOutputStream)方法，则通过底层进行调用  
23.          if (slotDesc.hasWriteObjectMethod()) {   
24.                 slotDesc.invokeWriteObject(obj, this);  
25.          }//如果没有此方法，则采用默认的写类数据域的方法。  
26.          else {//这个方法会对可序列化的对象中的数据域进行写出，但是如果这个数据域是不可序列化而且没有writeObject(ObjectOutputStream)方法的类对象，那么将抛出异常。  
27.         defaultWriteFields(obj, slotDesc);  
28.      }  
29. }  

         ObjectOutputStream中的writeSerialData()方法说明了JVM检查writeObject(ObjectOutputStream out)这个私有方法的潜在执行机制。这就是说，我们可以通过构造这个方法，使得原本不能序列化的类的部分数据域可以序列化。下面我们就开始对ZipFile进行可序列化的改造吧！

Java代码  

1. //自定义的一个可序列化的ZipFile，当然这个类不能继承JDK中的ZipFile，否则序列化将不可能完成。  
2. class SerializableZipFile implements Serializable{  
3.     public ZipFile zf;  
4.     //包含一个ZipFile对象  
5.     SerializableZipFile(String filename) throws IOException{  
6.         zf=new ZipFile(filename);  
7.     }  
8.     //对ZipFile中的文件名进行序列化，因为它是String类型的  
9.     private void writeObject(ObjectOutputStream out)throws IOException{  
10.         out.writeObject(zf.getName());  
11.     }  
12.     //对应的，反序列化过程中JVM也会检查类似的一个私有方法。  
13.     private void readObject(ObjectInputStream in)throws IOException,ClassNotFoundException{  
14.         String filename=(String)in.readObject();  
15.         zf=new ZipFile(filename);  
16.     }  
17. }  
18. //测试  
19. public static void main(String[] args) throws IOException, ClassNotFoundException{  
20.     //序列化  
21.         File file=new File("E:/aaa.txt");  
22.     ObjectOutputStream oout=new ObjectOutputStream(new FileOutputStream(file));  
23.     oout.writeObject(new SerializableZipFile("e:/aaa.zip"));  
24.     oout.close();  
25.     System.out.println("序列化成功");  
26.     //反序列化  
27.     ObjectInputStream oin=new ObjectInputStream(new FileInputStream(file));  
28.     Object o=oin.readObject();  
29.     oin.close();  
30.     System.out.println("反序列化成功:"+((SerializableZipFile) o).zf.getName());  
31. }  
32. //序列化成功  
33. //反序列化成功:e:\aaa.zip  

      太棒了，我们构造了一个可序列化的ZipFile类。这真是一件伟大的事情。

1、当父类继承Serializable接口，所有子类都可以被序列化
 2、子类实现了Serializable接口，父类没有，父类中的属性不能序列化（不报错，数据会丢失），但是子类中属性人能正确序列化
 3、如果序列化的属性是对象，这个对象也必须实现Serializable接口，否则会报错
 4、在反序列化时，如果对象的属性有修改或删减，修改的部分属性会丢失，但不会报错
 5、在反序列化时，如果serialVersionUID被修改，那么反序列化时会失败
 6、如果一个父类没有实现Serializable接口，他的内部类如果不是static的，即使实现了序列化接口，也会序列失败。
       因为非静态内部类会保存一个指向父类的类型this变量，而序列化类的所有属性必须实现序列化接口，所以要将内部类设置成静态类
 7、List或者Map容器中包含的泛型类型也必须实现Serializable接口，否则也会报java.io.NotSerializableException