EffectiveJava(笔记十) 序列化

序列化

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

74. 谨慎地实现Serializable接口

• 实现Serializable接口而付出的最大代价是, 一旦一个类被发布, 就大大降低了”改变这个类的实现”的灵活性: 如果一个类实现了序列化, 它的字节流编码就变成了它的导出的API的一部分, 一旦这个类被广泛使用, 往往必须永远支持这种序列化形式, 就好像你必须要支持导出的API的所有其他部分一样, 如果不努力设计一种自定义的序列化形式, 而仅仅接受了默认的序列化形式, 这种序列化形式将永远地束缚在改类最初的内部表示法上，序列化会使类的演变收到限制，这种限制的一个例子与流的唯一标识符有关，通常它被称为序列版本UID，每个序列化的类都有一个唯一的标识号与它相关联，如果没有在一个名为serialVersionUID的私有静态final的long域中显式地指定该符号，系统就会自动地根据这个类来调用一个复杂的运算过程，从而在运行时产生该标识号。类的成员或者方法改变了，自动产生的序列版本UID也会发生变化，因此，如果没有声明一个显式地序列版本UID，兼容性将会遭到破坏，运行时导致InvalidClassException异常。

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

• 实现Serializable的第三个代价是，随着类发行新的版本，相关的测试负担也增加了，当一个可序列化的类被修订的时候，很重要的一点是，要检查是否可以“在新版本中序列化一个实例，然后在旧版本中反序列化”，随着新的版本的不断发行，相关的测试工作量也大大增