第十一章        序列化

74、      谨慎地实现Serializable接口

实现Serializable接口而付出的最大代价是，一旦一个类被发布，就大降低了“改变这个类的实现”的灵活性。如采用默认的序列化方式时（仅实现Serializable），且没有在一个名为serialVersionUID的私有静态final的long域显示地指定该标识号，则如果类改变了，则会导致不兼容。

实现Serializable的第二个代价是，它增加了出现Bug和安全漏洞的可能性。反序列化过程不是调用原有的构造器，所以你很容易忘记要确保：反序列化过程必须也要保证所有“由真正的构造器建立起来约束关系”，并且不允许攻击者访问正在构造过程上的对象的内部信息，依靠默认的反序列化机制，很容易对象的约束关系遭到破坏，以及遭受非法访问（第76条）。

实现Serializable的第三个代价是，随着类发行新的版本，相关的测试负担也增加了。

实现Serializable接口并不是一个很轻松就可以做出的决定。根据经验，如Data和BigInteger这样的的值类应该实现Serializable，大多数的集合类也是应该如此。代表活动实体的类，如线程池，一般不应该实现Serializable。

为了继承而设计的类，应该尽可能少地去实现Serializable接口，用户的接口也应该尽可能少地继承Serializable接口。如果违反了这条规则，扩展这个类或者实现这个接口的程序员就会背上沉重的负担。然后在有些情况下是合适的，如，这个类或接口主要是为了参与到某个框架中，而该框架要求所有参与者都实现Serializable接口，则实现Serializable是有意义的。

对于为继承而设计的不可序列化的类，你应该考虑提供一个无参构造器，因为他的子类可能是可序列化的，一旦子类实现Serializable接口，则在反序列化时会调用调用父类的无参构造器。最好在所有约束关系都已经建立的情况下再创建对象。下面是一个父类不可序列化，而子类可序列化的建议做法：

与78条详细地讨论这个问题。

注，虽然lastName、firstName和middleInitial域是私有的，但它们依然有相应的文档注释。这是因为，这些私有域定义了一个公有的API，即这个类的序列化形式，并且该公有的API必须建立文档。

下面与Name不同，它是一个极端例子，该类表示了一个字符串列表：

public final class StringList implements Serializable {

private int size = 0;

private Entry head = null;

private static class Entry implements Serializable {

String data;

Entry next;

Entry previous;

}

... // Remainder omitted

}

从逻辑上讲，它表示一个字符序列，但从物理上看，它把字符串序列表示成了双向链表。如果你采用默认的序列化，它会将链表中的所有项都序列化。

当一个对象的物理表示法与它的逻辑数据内容有实质性的区别时，使用默认序列化形式会有以下缺点：

1、  它使这个类的导出API永远地束缚在该类的内部表示法上。上面例子中私有的StringList.Entry类变成了公有API的一部分。如果将来版本中内部表示法变化了，StringList仍将需接受链表形式的输入，并产生链表的输出。这个类永远也摆脱不掉维护链表项所需要的代码，即使不再使用链作为内部数据结构了，也仍需要这些代码。因为原来已序列化的二进对象在默认恢复过程中与当前版本类不兼容而导致反序列化失败，比如当前版本中少了某个域。

2、  它会消耗过多的空间与时间。上面的链表中的项的next、previouse是链表的实现实节，不用关心链接的物理信息，在恢复时是可以构造这些关系，不需要将它们一起序列化。

3、  它会引起栈溢出。默认的序列化过程要对对象图进行一次递归遍历，如果对象图层次很深的话很易容就会引起栈的溢出。

对于上面的StringList，我们只需要对size，与date逻辑数据进行序列化即可：

，布尔false。如果这些值不是你期望的，则需要在readObject方法中重新手动初始化。