第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条 考虑用序列化代理代替序列化实例
- 为可序列化的类设计一个私有的静态嵌套类,精确地表示外围类的实例的逻辑状态。这个嵌套类被称作序列化代理
- 它应该有一个单独的构造器,其参数类型就是那个外围类
- 这个构造器只从它的参数中复制数据:它不需要进行任何一致性检查或者保护性拷贝
- 序列化代理会有性能损失