跟我学（Effective Java 2）第74条:谨慎地实现Serializable接口

第74条:谨慎地实现Serializable接口

序列化（object serialization）API，它提供了一个框架，用来将对象编码成字节流，以及从字节流编码中重新构建对象。“将一个对象编码成一个字节流”，这就称作序列化（serializing）该对象；相反的处理过程被称作反序列化（deserializing）。

要想使一个类的实例可被序列化，非常简单，只要在它的声明中加入"implements Serializable"字样即可。虽然使一个类可被序列化的直接开销低到甚至可以忽略不计，但是为了序列化而付出的长期开销往往是实实在在的。

为实现Serializable而付出的最大代价是，一旦一个类被发布，就大大降低了"改变这个类的实现"的灵活性。 如果一个类实现了Serializable，它的字节流编码（或者说序列化形式，serialized form）就变成了它的导出的API的一部分。一旦这个类被广泛使用，往往必须永远支持这种序列化形式，就好像你必须要支持导出的API的所有其他部分一样。如果你不努力设计一个自定义的序列化形式（custom serialized form），而仅仅接受了默认的序列化形式，这种序列化形式将被永远地束缚在该类最初的内部表示法上。换句话说，如果你接受了默认的序列化形式，这个类中私有的和包级私有的实例域将都变成导出的API的一部分，这不符合"最低限度地访问域"的实践准则（见第13条），从而它就失去了作为信息隐藏工具的有效性。

如果你接受了默认的序列化形式，并且以后又要改变这个类的内部表示法，结果可能导致序列化形式的不兼容。客户端程序企图用这个类的旧版本来序列化一个类，然后用新版本进行反序列化，结果将导致程序失败。在改变内部表示法的同时仍然维持原来的序列化形式（使用ObjectOutputStream.putFields和ObjectInputStream.readFields），这也是可能的，但是做起来比较困难，并且会在源代码中留下一些可以明显的隐患。因此，你应该仔细地设计一种高质量的序列化形式，并且在很长时间内都愿意使用这种形式（见第75，78条）。这样做将会增加开发的初始成本，但这是值得的。设计良好的序列化形式也许会给类的演变带来限制；但是设计不好的序列化形式则可能会使类根本无法演变。

序列化会使类的演变受到限制，这种限制的一个例子与流的唯一标识符（stream unique identifier）有关，通常它也被称为序列版本UID（serial version UID）。每个可序列化的类都有一个唯一标识号与它相关联。如果你没有在一个名为serialVersionUID的私有静态final的long域中显式地指定该标识号，系统就会自动地将一个复杂的过程作用在这个类上，从而在运行时产生该标识号。这个自动产生的值会受到类名称、它所实现的接口的名称、以及所有公有的和受保护的成员的名称所影响。如果你通过任何方式改变了这些信息，比如，增加了一个不是很重要的工具方法，自动产生的序列版本UID也会发生变化。因此，如果你没有声明一个显式的序列版本UID，兼容性将会遭到破坏，在运行时导致InvalidClassException异常。

实现Serializable的第二个代价是，它增加了出现Bug和安全漏洞的可能性。 通常情况下，对象是利用构造器来创建的；序列化机制是一种语言之外的对象创建机制（extralinguistic mechanism）。无论你是接受了默认的行为，还是覆盖了默认的行为，反序列化机制（deserialization）都是一个"隐藏的构造器"，具备与其他构造器相同的特点。因为反序列化机制中没有显式的构造器，所以你很容易忘记要确保：反序列化过程必须也要保证所有"由构造器建立起来的约束关系"，并且不允许攻击者访问正在构造过程中的对象的内部信息。依靠默认的反序列化机制，可以很容易地使对象的约束关系遭到破坏，以及遭受到非法访问（见第76条）。

实现Serializable的第三个代价是，随着类发行新的版本，相关的测试负担也增加了。 当一个可序列化的类被修订的时候，很重要的一点是，要检查是否可以"在新版本中序列化一个实例，然后在旧版本中反序列化"，反之亦然。因此，测试所需要的工作量与"可序列化的类的数量和发行版本号"的乘积成正比，这个乘积可能会非常大。这些测试不可能自动构建，因为除了二进制兼容性（binary compatibility）以外，你还必须测试语义兼容性（semantic compatibility）。换句话说，你必须既要确保"序列化－反序列化"过程成功，也要确保结果产生的对象真正是原始对象的复制品。可序列化类的变化越大，它就越需要测试。如果在最初编写一个类的时候，就精心设计了自定义的序列化形式，测试的要求就可以有所降低，但是也不能完全没有测试。

实现Serializable接口并不是一个很轻松就可以做出的决定。它提供了一些实在的益处：如果一个类将要加入到某个框架中，并且该框架依赖于序列化来实现对象传输或者持久化，对于这个类来说，实现Serializable接口就非常有必要。更进一步来看，如果这个类要成为另一个类的一个组件，并且后者必须实现Serializable接口，若前者也实现了Serializable接口，它就会更易于被后者使用。 然而，有许多实际的开销都与实现Serializable接口有关。每当你实现一个类的时候，都需要权衡一下所付出的代价和带来的好处。根据经验，比如Date和BigInteger这样的值类应该实现Serializable，大多数的集合类也应该如此。代表活动实体的类，比如线程池（thread pool），一般不应该实现Serializable。

为了继承而设计的类（见第17条）应该很少实现Serializable，接口也应该很少会扩展它。如果违反了这条规则，扩展这个类或者实现这个接口的程序员就会背上沉重的负担。然而在有些情况下违反这条规则却是合适的。例如，如果一个类或者接口存在的目的主要是为了参与到某个框架中，该框架要求所有的参与者都必须实现Serializable，
那么，对于这个类或者接口来说，实现或者扩展Serializable就是非常有意义的。

为了继承而设计的类中真正实现了Serializable的有Throwable、Component和HttpServlet。因为Throwable实现了Serializable，所以RMI的异常可以从服务器端传到客户端。Component实现了Serializable，因此GUI可以被发送、保存和恢复。HttpServlet实现了Serializable，因此会话状态可以被缓存。

如果你实现了一个带有实例域的类，它是可序列化和可扩展的，你就应该担心这样一条告诫。

如果一个专门为了继承而设计的类不是可序列化的，就不可能编写出可序列化的子类。特别是，如果超类没有提供可访问的无参构造器，子类也不可能做到可序列化。因此，对于为继承而设计的不可序列化的类，你应该考虑提供一个无参构造器。

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

简而言之，千万不要认为实现Serializable会很容易。除非一个类在用了一段时间之后就会被抛弃，否则，实现Serializable就是个很严肃的承诺，必须认真对待。如果一个类是为了继承而设计的，则更加需要加倍小心。对于这样的类而言，在"允许子类实现Serializable"或"禁止子类实现Serializable"两者之间的一个折衷设计方案是，提供一个可访问的无参构造器。这种设计方案允许（但不要求）子类实现Serializable。