第85条 其他序列化优先于 Java 序列化
- 避免序列化漏洞被利用的最佳方法是永远不要反序列化任何东西
- 任何新系统中都没有理由使用 Java 序列化
- 永远不会反序列化不受信任的数据
- 推荐使用
JSON或protobuf替代序列化
第86条 谨慎地实现 Serializable 接口
- 实现 Serializable 接口而付出的最大代价是，一旦一个类被发布，就大大降低了“改变这个类的实现”的灵活性。如果你接受了默认的序列化形式，这个类中私有的和包级私有的实例域都将变成导出的 API 的一部分，这不符合"将域的访问权限限制到最低"的实践准则
- 实现 Serializable 的第二个代价是，它增加了出现 BUG 和安全漏洞的可能性
- 实现 Serializable 的第三个代价是，随着类发行新的版本，测试相关的负担也增加了
- 为了继承而设计的类应该很少实现
Serializable接口，接口也很少继承Serializable接口 - 内部类不应该实现 Serializable 接口
第87条 考虑使用自定义的序列化形式
- 如果一个对象的物理表示法等同于它的逻辑内容，可能就适合于使用默认的序列化形式
- 即使你确定了默认的序列化形式是合适的，通常还必须提供一个
readObject方法来保证约束关系和安全性 - 不管你选择了哪种序列化方式，都要为自己编写的每个可序列化的类声明一个显示的序列版本 UID
- 请勿更改序列版本UID
第88条 保护性地编写readObject方法
-
readObject方法实际上相当于另一个公有的构造器，如同其他的构造器一样，它也要满足所有注意事项。构造器必须检查其参数的有效性，并且在必要的时候对参数进行保护性拷贝，同样地，readObject方法也需要这么做 - 当一个对象反序列化的时候，对客户端不得拥有的对象引用的任何字段进行保护性拷贝至关重要
- 如果整个对象图在被反序列化之后必须进行验证，就应该使用 ObjectInputValidation 接口
第89条 对于实例控制，枚举类型优先于readResolve
- 如果依赖
readResolve进行实例控制，带有对象引用类型的所有实例域则都必须声明为transient的 -
readResolve的可访问性很重要 。如果把readResolve方法放在一个final类上，它就应该是私有的。如果把readResolve方法放在一个非final的类上，就必须认真考虑它的可访问性。如果它是私有的，就不适用于任何子类。如果它是包级私有的，就只适用于同一个包中的子类。如果它是受保护的或者公有的，就适用于所有没有覆盖它的子类。如果readResolve方法是受保护的或者公有的，并且子类没有覆盖它，对序列化过的子类实例进行反序列化，就会产生一个超类实例，这样有可能导致ClassCastException异常
第90条 考虑用序列化代理代替序列化实例
- 为可序列化的类设计一个私有的静态嵌套类，精确地表示外围类的实例的逻辑状态。这个嵌套类被称作序列化代理
- 它应该有一个单独的构造器，其参数类型就是那个外围类
- 这个构造器只从它的参数中复制数据：它不需要进行任何一致性检查或者保护性拷贝
- 序列化代理会有性能损失
