正如在第85和86项中提到并贯穿本章的讨论，实现Serializable的决定增加了出现bug和安全问题的可能性，因为它允许使用一种超语言机制来创建实例，而不是使用普通的构造函数。然而，有一种技术可以大大降低这些风险。这种技术称为序列化代理模式。
序列化代理模式相当简单。首先，设计一个私有静态嵌套类，它简洁地表示封闭类实例的逻辑状态。这个嵌套类称为封闭类的序列化代理。它应该有一个构造函数，其参数类型是封闭类。这个构造函数只是从它的参数复制数据:它不需要做任何一致性检查或防御性复制。按照设计，序列化代理的默认序列化形式是封闭类的完美序列化形式。必须声明所包含的类及其序列化代理才能实现Serializable。
例如，考虑第50项中编写的不可变周期类，并在第88项中使其可序列化。这是该类的序列化代理。句点非常简单，它的序列化代理具有与类完全相同的字段:
接下来，将以下writeReplace方法添加到所包含的类中。这个方法可以逐字复制到任何类与序列化代理:
该方法在封闭类上的存在导致序列化系统发出SerializationProxy实例，而不是封闭类的实例。换句话说，writeReplace方法在序列化之前将封闭类的实例转换为其序列化代理。
有了这个writeReplace方法，序列化系统将永远不会生成封闭类的序列化实例，但是攻击者可能会创建一个实例，试图违反类的不变量。为了保证这样的攻击会失败，只需将这个readObject方法添加到封闭的类中:
最后，在SerializationProxy类上提供一个readResolve方法，该方法返回封闭类的逻辑等效实例。此方法的存在导致序列化系统在反序列化时将序列化代理转换回封闭类的实例
这个readResolve方法仅使用其公共API创建了一个封闭类的实例，这就是该模式的美妙之处。它在很大程度上消除了序列化的语言外特性，因为反序列化实例是使用与任何其他实例相同的构造函数、静态工厂和方法创建的。这使您不必单独确保反序列化的实例遵从类的不变量。如果类的静态工厂或构造函数建立了这些不变量，而它的实例方法维护它们，那么您就确保了这些不变量也将通过序列化来维护。
下面是Period的readResolve方法。SerializationProxy上图:
与防御性复制方法(第357页)类似，序列化代理方法阻止伪字节流攻击(第354页)和内部字段盗窃攻击(第356页)。与前面的两种方法不同，此方法允许句点字段为final，这是
句点类是真正不可变的(第17项)。与前两种方法不同，这一种方法不需要太多的思考。你不用不得不找出哪些字段可能受到恶意序列化攻击的危害，也不需要显式地执行有效性检查作为反序列化的一部分。
序列化代理模式还有另一种方式比readObject中的防御性复制更强大。序列化代理模式允许反序列化实例具有与初始序列化实例不同的类。您可能不认为这在实践中有用，但它确实有用.
考虑EnumSet的情况(项目36)。该类没有公共构造函数，只有静态工厂。从客户机的角度来看，它们返回EnumSet实例，但是在当前OpenJDK实现中，它们返回两个子类中的一个，具体取决于底层enum类型的大小。如果底层enum类型有64个或更少的元素，则静态工厂返回一个RegularEnumSet;否则，它们返回一个JumboEnumSet。
现在考虑一下，如果序列化一个枚举类型有60个元素的枚举集，然后向枚举类型添加5个以上的元素，然后反序列化枚举集，会发生什么情况。序列化时它是RegularEnumSet实例，但反序列化后最好是JumboEnumSet实例。事实上正是这样，因为EnumSet使用序列化代理模式。如果您好奇，这里是EnumSet的序列化代理。其实很简单:
序列化代理模式有两个限制。它与用户可扩展的类不兼容(第19项)。而且，它与一些对象图包含循环的类不兼容:如果您试图从对象的序列化代理的readResolve方法中调用对象上的方法，您将得到一个ClassCastException，因为您还没有对象，只有对象的序列化代理。
最后，序列化代理模式的附加功能和安全性不是免费的。在我的机器上，序列化和反序列化要贵14%
使用序列化代理的句点实例比使用防御性复制的句点实例要多。
总之，当您发现必须在客户端不可扩展的类上编写readObject或writeObject方法时，请考虑序列化代理模式。这种模式可能是用非平凡不变量对对象进行鲁棒序列化的最简单方法。
本文写于2019.7.24，历时1天
