Effective Java 第二版第11章 序列化

11 序列化

序列化技术为远程通信提供了标准的线路级（wire-level）对象表示法，也为JavaBeans组件结构提供了表混的持久化数据格式。

第74条 谨慎地实现Serializable接口

实现Serializable接口的最大代价是：一旦一个类被发布，就大大降低了“改变这个类的实现”的灵活性。 如果一个类实现了Serializable接口，它的字节流编码就变成了它的导出的API的一部分。一旦这个类被广泛使用，往往必须永远支持这种序列化形式。如果你接受了默认的序列化形式，这个类中私有的和包级私有的实例域都将变成导出的API的一部分，这不符合“最低限度地访问域”的实践准则。

序列化会使类的演变受到限制。例如，流的唯一标识符（stream unique identifier，或者被称为序列版本UID serial version UID）。每个可序列化的类都有一个唯一的标识号与它相关联。如果你没有定义private staic final 的 serialVersionUID，系统会根据这个类来调用一个复杂的运算过程，从而在运行时产生该标识号。标识号的产生会受到类名称、所实现的接口名称和所有public、protected成员名称影响。如果类发生了变化，又没有定义serialVersionUID，兼容性会遭到破坏，在运行时导致InvalidClassException。
实现Serializable接口的第二个代价是：增加了出现bug和安全漏洞的可能性。 序列化机制是一种语言之外的对象创建机制（extralinguistic mechanism），是一种隐藏的构造器。反序列化过程中，必须也要保证所有“由真正的构造器建立起来的约束关系”，并且不允许攻击者访问正在构造过程中的对象的内部信息。依靠默认的反序列化机制，很容易使对象的约束关系遭到破坏，以及遭受到非法访问。
实现Serializable接口的第三个代价是：随着类发行新的版本，相关测试负担也增加了。当一个可被序列化的类被修订的时候，需要检查*“新版本中序列化一个实例，旧版本中能够成功反序列化，反之亦然”*。 测试的工作量与 “可序列化类的数量和发行版本号的乘积” 成正比。既要确保“序列-反序列化”过程的成功，也要确保产生的对象真的是原始对象的复制品。

根据经验，Date和BigInteger这样的类应该实现Serializable，大多数集合类也应该如此。代表活动实体的类，比如线程池（thread pool），一般不应该实现Serializable。

为了继承而设计的类应该尽可能少地去实现Serializable接口，用户的接口也应该尽可能少地继承Serializable接口。 但是有写情况下违反这条规则是合适的：如果一个类或者接口主要目的是为了参与到某个框架中，该框架所要求的所有参与者都不必须实现Serializable接口，那么，此时implement或者extend Serializable接口是合适的。为了继承而设计的类中，真正实现了Serializable接口的有Trowable（RMI异常可以从服务器端传到客户端）、Component（GUI可以被发送、保存和恢复）和HttpServlet（session state可以被缓存）抽象类。

如果类有一些约束条件，当类的实例域被初始化成它们的默认值时，就会违背这些约束条件，此时必须给这个类添加readObjectNoData方法。

如果一个类是不可序列化的，那个它的子类也是不可序列化的。特别地，如果超类没有提供可访问的无参构造器，子类也不可能做到可序列化。因此，对于为继承而设计的不可序列化的类，你应该提供一个无参构造器。

最好在所有约束关系都已经建立的情况下再创建对象。如果为了建立这些约束关系需要客户端提供一些数据，这实际上就排除了使用无参构造器的可能性。盲目地为一个类增加无参构造器和单独的初始化方法，而它的约束关系仍由其他的构造器来建立，这样做会使该类的状态空更加复杂，并且增加出错的可能性。

如下，可以给“不可序列化但可扩展的类”增加无参构造器，同时避免以上的不足。增加一个protected的构造器和一个初始化方法，初始化方法和正常的构造器有相同的参数。并且也能建立起同样的约束关系。AbstractFoo 中所有的public和protected的实例方法开始都会checkInit。这样就可以确保如果有编写不好的子类没有初始化实例，该方法调用直接就失败。init域是一个原子引用，用来确保对象的完整性。

package rule74;

import java.util.concurrent.atomic.AtomicReference;

public abstract class AbstractFoo {
    private int x;

    private int y;

    private enum State {NEW, INITIALIZING, INITIALIZED};
    private final AtomicReference<State> init = new AtomicReference<>(State.NEW);

    public AbstractFoo(int x, int y) {
        initialize(x, y);
    }

    protected AbstractFoo() {

    }

    protected final void initialize(int x, int y) {
        if (!init.compareAndSet(State.NEW, State.INITIALIZING)) {
            throw new IllegalStateException("Already initialized");
        }

        this.x = x;
        this.y = y;

        init.set(State.INITIALIZED);
    }

    protected final int getX() {
        checkInit();
        return x;
    }

    protected final int getY() {
        checkInit();
        return y;
    }

    private void checkInit() {
        if (init.get() != State.INITIALIZED) {
            throw new IllegalStateException("Uninitialized");
        }
    }
}

package rule74;

import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.io.Serializable;

public class Foo extends AbstractFoo implements Serializable {
    private static final long serialVersionUID = 185683586095L;
    
    public Foo(int x, int y) {
        super(x, y);
    }
    private void readObject(ObjectInputStream s) throws IOException, ClassNotFoundException {
        s.defaultReadObject();

        int x = s.readInt();
        int y = s.readInt();
        initialize(x, y);
    }

    private void writeObject(ObjectOutputStream s) throws IOException {
        s.defaultWriteObject();

        s.writeInt(getX());
        s.writeInt(getY());
    }
}

内部类不应该实现Serializable。内部类使用编译器产生的合成域（synthetic field）来保存指向外围实例（enclosing instance）的引用，以及保存来自外围作用域的局部变量的值。“这些类如何对应到类定义中”并没有明确的规定，就好像没有指定匿名类和局部类的名称一样。因此，内部类的默认序列化形式是定义不清楚的。但是，静态成员类是可以实现Serializable接口的。

第75条 考虑使用自定义的序列化形式

如果没有先认真考虑默认的序列化形式是否合适，则不要贸然接受。接受默认的序列化形式需要你从灵活性、性能和正确性多个角度对这种编码形式进行考察。一般来讲，只有你自行设计的序列化形式和默认的序列化形式基本相同时，才能接受默认的序列化形式。

对于一个对象来说，理想的序列化形式应该只包含该对象的逻辑数据，而逻辑数据与物理表示法应该是各自独立的。

如果一个对象的物理表示法等同于它的逻辑内容，可能就适合于使用默认的序列化形式。例如下面这个表示人名的类，使用默认的序列化形式是合理的。

/**
 * 功能描述
 *
 * @since 2022-09-05
 */
public class Name implements Serializable {
    private final String lastName;

    private final String firstName;

    private final String middleName;
}

从逻辑角度而言，一个名字就包含姓、名和中间名。Name中的实例域精确地反应了它的逻辑内容。

即使你确定了默认的序列化形式是合适的，通常还必须提供一个readObject方法以保证约束关系和安全性。对Name这个类而言，readObject方法必须确保lastName和firstName是非null的。

看下面这个另一个极端的例子

public class StringList implements Serializable {
    private int size = 0;
    private Entry head = null;

    private static class Entry implements Serializable {
        String data;
        Entry next;
        Entry previous;
    }
}

从逻辑角度讲，这个类表示了一个字符串序列，但是从物理意义上讲，序列被表示成了一个双向链表。如果使用了默认的序列化形式，该序列化形式将不遗余力地镜像出链表中的所有项，以及这些项之间的所有双向链表。

当一个对象的物理表示法与它的逻辑数据内容有实质性的区别的时候，使用默认的序列化形式有如下4个缺点：
（1）它使这个类的导出API永远地束缚在该类的内部表示法上。 在上面的例子中，StringList.Entry变成了公有API的一部分。如果在将来的版本中，内部表示法发生了变化，StringList类仍然需要接收链表形式的输入，并产生链表形式的输出。这个类永远也摆脱不掉维护链表所需要的所有的代码。即便是它不再使用链表作为内部数据结构了，也仍然需要这些代码。
（2）它会消耗过多的空间。 在StringList的例子中，序列化形式既表示了链表中的每个项，也表示了所有的连接关系（这个是没有必要的）。链表项和链接关系是实现细节，没有必要记录在序列化形式当中。
（3）它会消耗过多的时间。 序列化逻辑并不了解对象图的拓扑关系，所以它必须经过一个昂贵的图遍历的过程。
（4）它会引起栈溢出。 默认的序列化过程需要对对象图执行一次递归遍历，即时对于中等规模的对象图，这样的操作也会引起栈溢出。

对于StringList类，合理的序列化形式只需要先包含链表中字符串的数目，然后跟着这些字符串即可。这样就构成了StringList所表示的逻辑数据，与其物理表示细节脱离。下面是StringList的修订版本。

public class StringList 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) {
        s.defaultWriteObject();
        s.writeInt(size);

        for (Entry e = head; e != null; e = e.next) {
            s.writeObject(e.data);
        }
    }

    private void readObject(ObjectInputStream s) {
        s.defaultReadObject();
        int numElements = s.readInt();

        for (int i = 0; i < numElements; i++) {
            add((String) s.readObject());
        }
    }
}

尽管StringList的所有的域都是transient，readObject和writeObject两个方法都要先进行默认的读写。从技术角度讲，如果所有的field都是transient（瞬时的），可以不先进行默认的读写，但是不推荐这样做。 defaultReadObject或者defaultWriteObject会极大地增强灵活性，并且还能保持向前或者向后的兼容性。

考虑散列表。一个项被放在哪个桶中，不同的JVM实现不保证会有同样的结果。实际上，即时在同一个JVM实现中，也无法保证每次运行都是一样的。因此，对于散列表而言，接受默认的序列化形式会造成一个严重的bug。对散列表对象进行序列化和反序列化操作所产生的对象，其约束关系会遭到严重的破坏。

当defaultWriteObject方法被调用的时候，每一个未被标记为transient的域都会被序列化。因此，每一个可以被标记为transient的实例域都应该被标记。在决定将一个域做成非transient之前，请一定要确信它的值将是该对象逻辑状态的一部分。

对于默认的序列化形式，transient的域在反序列化的时候，会被初始化为默认值。如果默认值不被transient修饰的域接受，那么，应该提供一个readObject方法，先调用defaultReadObject，然后将这些transient的域恢复为可接受的值。另一种方法就是延迟初始化。

无论是否使用默认的序列化形式，如果在读取整个对象状态的任何其他方法上强制任何同步，则也必须在对象序列化上强制这种同步。因此，如果你有一个线程安全的对象，它通过同步每个方法实现了线程安全，并且使用默认的序列化形式，就要使用如下的writeObject方法。

private synchronized void writeObject(ObjectOutputStream s) throws IOException {
	s.defaultWriteObject();
}

第76条 保护性地编写readObject方法

public class Period {
    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());
    }

    @Override
    public String toString() {
        return "Period{" +
            "start=" + start +
            ", end=" + end +
            '}';
    }
}

上面是一个不可变的日期范围类。该类通过在构造方法和访问方法中保护性拷贝Date对象，极力地维护其约束条件和不可变性。如果你直接implements Serializable，那么这个类将不再保证其关键约束了。

readObject方法相当于另一个公有的构造器。readObject也需要检查其参数的有效性，并且在必要的时候对参数进行保护性的拷贝。

当一个对象被反序列化的时候，对于客户端不应该拥有的对象引用，如果哪个域包含了这样的对象引用，就必须要做保护性拷贝，这是非常重要的。 对于每个可序列化的不可变类，如果它包含了私有的可变组件，那么在它的readObject方法中，必须要对这些组件进行保护性拷贝。注意，保护性拷贝是在有效性检查之前进行的。

对于非final的可序列化的类，readObject方法不可以调用可以被覆盖的方法，无论是直接调用或者是间接调用都不可以。 如果违反了这条规则，并且覆盖了该方法，被覆盖的方法将在子类的状态被发序列化之前先运行，程序很可能就会失败。

编写出强壮的readObject方法的指导方针：

• 对于对象引用域必须保持为私有的类，要保护性地拷贝这些域中的每个对象。不可变类的可变组件就属于这一类别。
• 对于任何约束条件，如果检查失败，则抛出一个InvalidObjectException异常。这些检查动作应该跟在所有的保护性拷贝之后。
• 如果这个对象图在被反序列化之后必须进行验证，就应该使用ObjectInputValidation接口。
• 无论是直接还是间接方式，都不要调用类中任何可以被覆写的方法。

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

public class Elvis {
    public static final Elvis INSTANCE = new Elvis();

    private Elvis() {}
}

对于Elvis 这个类来说，如果继承了Serializable接口的话，就不再是一个单例了。无论使用的是默认的序列化形式还是自定义的序列化形式。也跟是否显示的提供了readObject方法也无关。任何一个readObject方法都会返回一个新的实例，新建的实例不同于类初始化时创建的实例。

readResolve特性允许readObject创建的对象代替另一个实例。在发序列化之后，新建的对象的readResolve方法就会被调用，readResolve方法的返回值就会取代掉反序列化新创建的实例。 例如：

    private Object readResolve() {
        return INSTANCE;
    }

如果依赖readResolve进行实例控制，带有对象引用类型的所有实例域都必须被声明为transient。

总之，尽可能的使用枚举类型来实施实例控制的约束条件。JVM对枚举类型的单例提供了保障。如果不使用枚举，并且需要一个既可序列化又是实例受控的（instance-controlled）类，就必须提供一个readResolve方法，并且确保该类的所有实例域都为基本类型的，或者是transient的。

第78条 考虑用序列化代理代替序列化实例

序列化代理模式（serialization proxy pattern）：（1）为可序列化的类设计一个私有的静态嵌套类，用来表示外围类的逻辑状态。这个嵌套类就是序列化代理。（2）序列化代理类有一个构造器，构造器参数就是外围类。构造器只从它的参数中复制数据，不需要进行任何的一致性检查或者保护性拷贝。（3）外围类及其序列化代理类都必须声明实现Serializable接口。

public 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());
    }

    @Override
    public String toString() {
        return "Period{" +
            "start=" + start +
            ", end=" + end +
            '}';
    }

    private Object writeRepalace() {
        return new SerializationProxy(this);
    }

    private void readObject(ObjectInputStream stream) throws InvalidObjectException {
        throw new InvalidObjectException("Proxy required");
    }

    private static class SerializationProxy implements Serializable {
        private static final long seriousVersionUID = 1L;

        private final Date start;
        private final Date end;

        SerializationProxy(Period period) {
            this.start = period.start;
            this.end = period.end;
        }

        private Object readResolve() {
            return new Period(start, end);
        }
    }
}

序列化代理模式有两个局限性：（1）不能与可以被客户端扩展的类兼容。（2）不能与对象图中包含循环的某些类兼容：如果你企图从一个对象的序列化代理的readResolve方法内部调用这个对象中的方法，就会得到一个ClassCastException异常，因为你还没有这个对象，只有它的序列化代理。
序列化代理模式有一个代价：通过序列化代理来进行序列化和反序列化的开销要被保护性拷贝要高。