Effective Java - 序列化

第85条 其他序列化优先于 Java 序列化

1. 避免序列化漏洞被利用的最佳方法是永远不要反序列化任何东西
2. 任何新系统中都没有理由使用 Java 序列化
3. 永远不会反序列化不受信任的数据
4. 推荐使用JSON或protobuf替代序列化

第86条 谨慎地实现 Serializable 接口

1. 实现 Serializable 接口而付出的最大代价是，一旦一个类被发布，就大大降低了“改变这个类的实现”的灵活性。如果你接受了默认的序列化形式，这个类中私有的和包级私有的实例域都将变成导出的 API 的一部分，这不符合"将域的访问权限限制到最低"的实践准则
2. 实现 Serializable 的第二个代价是，它增加了出现 BUG 和安全漏洞的可能性
3. 实现 Serializable 的第三个代价是，随着类发行新的版本，测试相关的负担也增加了
4. 为了继承而设计的类应该很少实现Serializable接口，接口也很少继承Serializable接口
5. 内部类不应该实现 Serializable 接口

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

1. 如果一个对象的物理表示法等同于它的逻辑内容，可能就适合于使用默认的序列化形式
2. 即使你确定了默认的序列化形式是合适的，通常还必须提供一个readObject方法来保证约束关系和安全性
3. 不管你选择了哪种序列化方式，都要为自己编写的每个可序列化的类声明一个显示的序列版本 UID
4. 请勿更改序列版本UID

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

1. readObject方法实际上相当于另一个公有的构造器，如同其他的构造器一样，它也要满足所有注意事项。构造器必须检查其参数的有效性，并且在必要的时候对参数进行保护性拷贝，同样地，readObject方法也需要这么做
2. 当一个对象反序列化的时候，对客户端不得拥有的对象引用的任何字段进行保护性拷贝至关重要
3. 如果整个对象图在被反序列化之后必须进行验证，就应该使用 ObjectInputValidation 接口

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

1. 如果依赖readResolve进行实例控制，带有对象引用类型的所有实例域则都必须声明为transient的
2. readResolve的可访问性很重要 。如果把readResolve方法放在一个final类上，它就应该是私有的。如果把readResolve方法放在一个非final的类上，就必须认真考虑它的可访问性。如果它是私有的，就不适用于任何子类。如果它是包级私有的，就只适用于同一个包中的子类。如果它是受保护的或者公有的，就适用于所有没有覆盖它的子类。如果readResolve方法是受保护的或者公有的，并且子类没有覆盖它，对序列化过的子类实例进行反序列化，就会产生一个超类实例，这样有可能导致ClassCastException异常

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

1. • 为可序列化的类设计一个私有的静态嵌套类，精确地表示外围类的实例的逻辑状态。这个嵌套类被称作序列化代理
   • 它应该有一个单独的构造器，其参数类型就是那个外围类
   • 这个构造器只从它的参数中复制数据：它不需要进行任何一致性检查或者保护性拷贝
2. 序列化代理会有性能损失