本章关注对象序列化API，它提供了一个框架，用来将对象编码成字节流，并从字节流编码中重新构建对象。 相反的处理过程是反序列化deserializing。一旦对象被序列化后，它的编码就可以从一台正在运行的虚拟机被传递到另一台虚拟机上，或者被存储到磁盘上，供以后反序列化时用。序列化技术为远程通信提供了标准的线路级对象表示法，也为JavaBean组件结构提供了标准的持久化数据格式。

第七十四条、谨慎地实现Serializable接口

要想使一个类的实例可以被序列化，只要在它的声明中加入implements Serializable字样即可，但实际情况可能要复杂得多，虽然使一个类可被实例化的直接开销非常低，但是为了序列化而付出的长期开销往往是实实在在的。
实现Serializable接口的代价：
- 最大的代价是：一旦一个类被发布，就大大降低了“改变这个类的实现”的灵活性。
  
  如果一个类实现了Serializable接口，它的字节流编码就变成了它导出的API的一部分，一旦这个类被广泛使用，往往永远支持这个序列化形式。如果你接受了默认的序列化形式，并且以后又要修改这个类的内部表示法，可能会导致序列化形式的不兼容。
  
  序列化会使类的演变受到限制，这种限制的一个例子与流的唯一标识符有关，通常它也被称为序列版本UID（serialVersionUID），每个可序列化的类都有一个唯一标识号与它相关联。如果你没有显式地指定该标识号（private static final long serialVersionUID = ...），系统就会自动地在运行时产生该标识号。这个自动产生的值会受到类名称、它实现的接口名称、以及所有的公有和受保护的成员的名称所影响。因此，如果你没有声明一个显式的序列版本UID，兼容性会遭到破坏。
- 第二个代价是：它增加了出现Bug和安全漏洞的可能性。通常情况下，对象是通过构造器来创建的；序列化机制是一种语言之外的对象创建机制。反序列化机制是一个隐藏的构造器，依靠默认的反序列化机制，很容易使对象的约束关系遭到破坏，以及遭受非法访问。
- 第三个代价：随着类发行新的版本，相关的测试负担也增加了。
实现Serializable接口提供了实在的好处：

如果一个类将要加入到某个框架中，并且该框架依赖于序列化来实现对象传输或者持久化，对于这个类来说，实现Serializable接口就非常有必要。
为了继承而设计的类应该尽可能少地去实现Serializable接口，用户的接口也应该尽可能少地实现。如果违反了这条规则，扩展这个类或者实现这个接口的程序员就会背上沉重的负担。但是有例外：Throwable（RMI的异常可以从服务器端传到客户端）类，Component（GUI可以被发送、保存和恢复）和HttpServlet抽象类（会话状态可以被缓存）。
内部类（inner class）不应该实现Serializable，它们使用编译器产生的合成域来指向外围实例的引用，以及保存来自外围作用域的局部变量的值。

第七十五条、考虑使用自定义的序列化形式

如果没有先认真考虑默认的序列化形式是否合适，则不要贸然接受。接受默认的序列化形式是一个非常重要的决定。需要从灵活性、性能和正确性多个角度对这种编码形式进行考察。
默认的序列化形式描述了该对象内部所包含的数据，以及每一个可以从这个对象到达的其他对象的内部数据。它也描述了所有这些对象被链接起来后的拓扑结构。对于一个对象来说，理想的序列化形式应该只包含该对象所表示的逻辑数据，而逻辑数据与物理表示法应该是各自独立的。如果一个对象的物理表示法等同于它的逻辑内容，可能就适合于使用默认的序列化形式。即使你确定了默认的序列化形式是合适的，通常还必须提供一个readObject方法以保证约束关系和安全性。
当一个对象的物理表示法与它的逻辑数据内容有实质性区别的时候，使用默认的序列化形式会有以下四个缺点：
- 它使这个类的导出API永远地束缚在该类的内部表示法上；
- 它会消耗过多的空间；
- 它会消耗过多的时间；
- 它会引起栈溢出。

合理的序列化形式实例：

writeObject方法的首要任务是调用defaultWriteObject,readObject的首要方法是调用defaultReadObject。无论你是否使用默认的序列化形式，当defaultWriteObject方法被调用的时候，每个未被标记为transient的实例域都会被序列化。在决定将一个域做成非transient的之前，请一定要确信它的值将是该对象逻辑状态的一部分。如果要自定义序列化形式，大多数或者所有的实例域都应该标记为transient。

    import java.io.IOException;
    import java.io.ObjectInputStream;
    import java.io.ObjectOutputStream;
    import java.io.Serializable;
    
    /**
     * Created by laneruan on 2017/8/3.
     * 一个自定义的序列化形式实例
     */
    public class StringListSerialization implements Serializable {
        private transient int size = 0;     //瞬时的
        private transient Entry head = null;
    
        private static class Entry{
            String data;
            Entry next;
            Entry previous;
        }
    
        public final void add(String s){
    
        }
    
        private void writeObject(ObjectOutputStream s)
            throws IOException{
            s.defaultWriteObject();
            s.writeInt(size);
            for(Entry e = head;e!=null; e= e.next){
                s.writeObject(e.data);
            }
        }
        private void readObject(ObjectInputStream s)
            throws IOException,ClassNotFoundException{
            s.defaultReadObject();
            int numElements = s.readInt();
    
            for(int i = 0;i

 
  对于有些对象的约束关系要依赖于特定的实现细节，用默认的序列化形式会破坏其约束关系。比如考虑散列表的情形。 
   如果正在使用默认的序列化形式，并且把一个或者多个域标记为transient，则需要记住：当一个实例被反序列化的时候，这些域将被初始化为它们的默认值（default value）： 
    
    对于对象引用域，默认值为null。
 对于数值基本域，默认值为0。
 对于boolean域，默认值为false。
 如果这些值不能被任何transient域所接受，则必须要提供readObject方法，它首先调用defaultreadObject方法，再把这些transient域恢复为可接受的值。 
   
  
   无论是否使用默认形式，都需要注意： 
    
     如果在读取整个对象状态的任何其他方法上强制任何同步，则也必须在对象序列化上强制这种同步。如果把同步放在writeObject方法上，就必须确保它遵守与其他动作相同的锁排列约束条件。
     private synchronized void writeObject(ObjectOutputStream s)
        throws IOException{
        s.defaultWriteObject();
    }
  
    要为自己编写的每个可序列的类声明一个显式的序列版本UID。这样可以避免序列版本UID成为潜在的不兼容根源，且带来小小的性能优势。
 private static final long serialVersionUID = randomLongValue;

 
  
 第七十六条、保护性地编写readObject方法 
  
  每当你编写readObject方法的时候，都要这样想：你正在编写一个公有的构造器，无论给它传递什么样的字节流，它都必须产生一个有效的实例，不要假设这个字节流一定代表着一个真正被序列化过的实例，下面给出一些指导性建议，有助于编写出更加健壮的readObject方法： 
    
    对于对象引用域必须保持为私有的域，要保护性地拷贝这个域中的每个对象，不可变类的可变组件就属于这一类别； 
    对于任何约束条件，如果检查失败，则抛出一个InvalidObjectException，这些检查动作应该跟在所有的保护性拷贝后面； 
    如果整个对象图在被反序列化之后必须进行验证，就应该使用ObjectInputValidation接口； 
    无论是直接还是间接方式，都不要调用类中任何可被覆盖的方法。 
   
  
  
  
 第七十七条、对于实例控制，枚举类型优先于readResolve 
  
  之前讲过的Singleton模式，一般这种类限制了构造器的访问，以确保永远只创建一个实例。但是，如果这种类的声明加上了implements Serializable，就不再是Singleton。任何一个readObject方法，都会返回一个新建的实例，这个新建的实例不同于该类初始化时创建的实例。 
  readSolve特性允许你用readObject创建的实例代替另一个实例，对于一个正在被反序列化的对象，如果它的类定义了一个readSolve方法，并且具备正确的声明，那么反序列化之后，新建对象上的readSolve方法就会被调用，然后，该方法返回的对象引用将被返回，取代新建的对象。如果依赖readSolve进行实例控制，带有引用类型的所有实例域则都必须声明为transient的。 
   如果将一个可序列化的实例受控类编写成枚举，就可以绝对保证除了所声明的常量之外，不会有别的实例（JVM保证的）
     import java.io.Serializable;
    import java.util.Arrays;
    
    /**
     * Created by laneruan on 2017/8/3.
     */
    public class singletonReadSolve implements Serializable {
        public static final singletonReadSolve INSTANCE = new singletonReadSolve();
        private singletonReadSolve(){}
        //这个方法足以保证Singleton属性
        private String[] favoriteSongs = {"Hound dog","Heartbreak Hotel"};
        public void printFavorites(){
            System.out.println(Arrays.toString(favoriteSongs));
        }
        private Object readResolve(){
            return INSTANCE;
        }
        //用enum类型进行实例控制
        public enum singletonEnum{
            INSTANCE;
            private String[] favoriteSongs = {"Hound dog","Heartbreak Hotel"};
            public void printFavorites(){
                System.out.println(Arrays.toString(favoriteSongs));
            }
        }
    }

  
  readResolve的可访问性很重要，如果把它放在一个final类上，就应该是私有的，如果放在非final类上，就必须认真考虑它的访问性。 
  总结：应该尽可能使用枚举类型来实施实例控制的约束条件，如果做不到，同时有需要一个既可以序列化优势实例受控的类，就必须提供一个readResolve方法，并确保该类的所有实例域都是基本类型或者是transient的。 
  
  
 第七十八条、考虑用序列化代理代替序列化实例 
  
   序列化代理模式（serialization proxy pattern）：首先，为可序列化的类设计一个私有的静态嵌套类，精确地表示外围类的实例的逻辑状态。这个嵌套类称为序列化代理，它有一个单独的构造器，其参数就是那个外围类，这个构造器只从它的参数中复制数据。外围类和其序列代理都必须声明实现Serializable接口。
     import java.io.InvalidObjectException;
    import java.io.ObjectInputStream;
    import java.io.Serializable;
    import java.util.Date;
    
    /**
     * Created by laneruan on 2017/8/3.
     *
     */
    
    //代理类SerializationProxy
    public class SerializationProxy implements Serializable{
        private final Date start;
        private final Date end;
    
        SerializationProxy(Period p){
            this.start = p.start();
            this.end = p.end();
        }
        private static final long serialVersionUID = 234038490L;
        private void readObject(ObjectInputStream stream)
                throws InvalidObjectException{
            throw new InvalidObjectException("Proxy required");
        }
        //它返回一个逻辑上的外围类实例，这是该模式的魅力所在
        // 导致序列化系统在反序列化时将序列化代理类转变回外围类的实例
        private Object readResolve(){
            return new Period(start,end);
        }
    }
    //外围类Period
    class Period implements Serializable{
        private final Date start;
        private final Date end;
        public Period(Date start,Date end){
            this.start = new Date(start.getTime());
            this.end = new Date(end.getTime());
            if(this.start.compareTo(this.end)>0){
                throw new IllegalArgumentException(start + "after" + end);
            }
        }
        public Date start(){return new Date(start.getTime());}
        public Date end(){return new Date(end.getTime());}
        public String toString(){
            return start + "-" + end;
        }
        //有了这个方法，序列化系统永远不会产生外围类的序列化实例
        private Object writeReplace(){
            return new SerializationProxy(this);
        }
    }

  
  这种代理模式的优点：不必太费心思，不必显式地执行有效性检查，不必知道哪些域可能会受到狡猾的序列化攻击的危险。 
  序列化代理模式的两个局限：不能与可以被客户端扩展的类兼容，也不能与对象图中包含循环的某些类兼容；开销增大。 
  总结：当你发现自己必须在一个不能被客户端扩展的类上编写readObject或者writeObject的时候，就应该考虑使用序列化代理模式；想要稳健地将带有重要约束条件的对象序列化时，这种模式可能是最容易的方法。

第十一章、序列化

第七十四条、谨慎地实现Serializable接口

第七十五条、考虑使用自定义的序列化形式

第七十六条、保护性地编写readObject方法

第七十七条、对于实例控制，枚举类型优先于readResolve

第七十八条、考虑用序列化代理代替序列化实例

你可能感兴趣的:(第十一章、序列化)