欢迎大家关注 github.com/hsfxuebao/j… ，希望对大家有所帮助，要是觉得可以的话麻烦给点一下Star哈
本章涉及对象序列化（object serialization），它是Java的框架，用于将对象编码为字节流（序列化）并从其编码中重构对象（反序列化）。 一旦对象被序列化，其编码可以从一个虚拟机发送到另一个虚拟机或存储在磁盘上以便以后反序列化。 本章重点介绍序列化的风险以及如何将序列化的风险最小化。
85. 其他替代方式优于Java本身序列化
当序列化在1997年添加到Java中时，它被认为有一定的风险。这种方法曾在研究语言(模块3)中尝试过，但从未在生产语言中使用过。虽然程序员不费什么力气就能实现分布式对象的承诺很吸引人，但代价是不可见的构造方法和API与实现之间模糊的界线，可能会出现正确性、性能、安全性和维护方面的问题。支持者认为收益大于风险，但历史证明并非如此。
本书前几版中描述的安全问题与一些人担心的一样严重。 2000年之前中讨论的漏洞在未来十年被转化为严重漏洞，其中最著名的包括2016年11月对旧金山大都会运输署(San Francisco Metropolitan Transit Agency)市政铁路(SFMTA Muni)的勒索软件攻击，导致整个收费系统关闭了两天[Gallagher16]。
序列化的一个基本问题是它的攻击面太大而无法保护，而且还在不断增长：通过调用ObjectInputStream类上的readObject方法反序列化对象图。这个方法本质上是一个神奇的构造方法，可以用来实例化类路径上几乎任何类型的对象，只要该类型实现Serializable接口。在反序列化字节流的过程中，此方法可以执行来自任何这些类型的代码，因此所有这些类型的代码都是攻击面的一部分。
攻击面包括Java平台类库中的类，第二方类库（如Apache Commons Collections）和应用程序本身。 即使你遵守所有相关的最佳实践并成功编写无法攻击的可序列化类，你的应用程序仍可能容易受到攻击。 引用CERT协调中心技术经理Robert Seacord的话：
Java反序列化是一个明显且存在的危险，因为它直接被应用程序广泛使用，并间接地由Java子系统（如RMI（远程方法调用），JMX（Java管理扩展）和JMS（Java消息系统））广泛使用。 不受信任的流的反序列化可能导致远程代码执行（RCE），拒绝服务（DoS）以及一系列其他漏洞利用。 应用程序即使没有做错也容易受到这些攻击。[Seacord17]
攻击者和安全研究人员研究Java类库和常用的第三方类库中的可序列化类型，寻找在反序列化过程中调用的执行潜在危险活动的方法。这种方法称为gadget。多个gadget可以同时使用，形成一个gadget链（chain）。偶尔会发现gadget链，它的功能足够强大，允许攻击者在底层硬件上执行任意的本机代码，只要有机会提交精心设计的字节流进行反序列化。这正是SFMTA Muni袭击中发生的事情。这次袭击并不是孤立事件。已经发生过，而且还会有更多。
不使用任何gadget，就可以通过导致需要很长时间反序列化的短字节流，进行反序列化操作，轻松地发起拒绝服务攻击。这种流被称为反序列化炸弹(deserialization bombs)[Svoboda16]。下面是Wouter Coekaerts的一个例子，它只使用HashSet和字符串[Coekaerts15]:
// Deserialization bomb - deserializing this stream takes forever
static byte[] bomb() {
Set<Object> root = new HashSet<>();
Set<Object> s1 = root;
Set<Object> s2 = new HashSet<>();
for (int i = 0; i < 100; i++) {
Set<Object> t1 = new HashSet<>();
Set<Object> t2 = new HashSet<>();
t1.add("foo"); // Make t1 unequal to t2
s1.add(t1); s1.add(t2);
s2.add(t1); s2.add(t2);
s1 = t1;
s2 = t2;
}
return serialize(root); // Method omitted for brevity
}
对象图由201个HashSet实例组成，每个实例包含3个或更少的对象引用。整个流的长度为5744字节，但是在完成反序列化之前，太阳都已经耗尽了。问题是反序列化HashSet实例需要计算其元素的哈希码。root实例的2个元素本身就是包含2个HashSet元素的HashSet，每个HashSet元素包含2个HashSet元素，以此类推，深度为100。因此，反序列化set会导致hashCode方法被调用超过2100次。除了反序列化会持续很长时间之外，反序列化器没有任何错误的迹象。生成的对象很少，并且堆栈深度是有界的。
那么你能做些什么来抵御这些问题呢？ 每当反序列化你不信任的字节流时，就会打开攻击。 避免序列化漏洞利用的最佳方法是永远不要反序列化任何东西。用1983年电影《战争游戏》(WarGames)中名为约书亚(Joshua)的电脑的话来说，“唯一的制胜的招式就是不玩”。没有理由在你编写的任何新系统中使用Java序列化。 还有其他在对象和字节序列之间进行转换的机制，可以避免Java序列化的许多危险，同时提供许多优势，例如跨平台支持，高性能，大型工具生态系统以及广泛的专业知识社区。 在本书中，我们将这些机制称为跨平台结构化数据表示（ cross-platform structured-data representations）。 虽然其他人有时将它们称为序列化系统，但本书避免了这种用法，以防止与Java序列化混淆。
这些表示的共同点是它们比Java序列化简单得多。它们不支持任意对象图的自动序列化和反序列化。相反，它们支持由一组属性值对（attribute-value pairs）组成的简单结构化数据对象。只支持少数基本数据类型和数组数据类型。事实证明，这个简单的抽象足以构建功能极其强大的分布式系统，而且足够简单，可以避免Java序列化从一开始就存在的严重问题。
领先的跨平台结构化数据表示是JSON [JSON]和Protocol Buffers，也称为protobuf [Protobuf]。 JSON由Douglas Crockford设计用于浏览器——服务器通信，并且Protocol Buffers由Google设计用于在其服务器之间存储和交换结构化数据。 即使这些表示有时被称为中立语言（language-neutral），JSON最初是为JavaScript开发的，而protobuf是为C++开发的; 这两种表述都保留了其起源的痕迹。
JSON和protobuf之间最显着的区别是JSON是基于文本的，人类可读的，而protobuf是二进制的，而且效率更高； JSON是一种专门的数据表示，而protobuf提供模式（类型）来文档记录和执行适当的用法。 尽管protobuf比JSON更有效，但JSON对于基于文本的表示非常有效。 虽然protobuf是二进制表示，但它确实提供了一种替代文本表示，用于需要人们可读性的地方（pbtxt）。
如果不能完全避免Java序列化，可能需要在它的遗留系统环境里中工作，那么下一个最佳选择就是永远不要反序列化不受信任的数据。特别是，不应该接受来自不可信源的RMI流量。Java的官方安全编码指南说“反序列化不受信任的数据本质上是危险的，应该避免。这句话是用大号、粗体、斜体和红色字体设置的，它是整个文档中唯一应用这种处理([Java-secure)的文本。
如果无法避免序列化，并且不能绝对确定反序列化数据的安全性，那么可以使用Java 9中添加的对象反序列化过滤器，并将其移植到早期版本(Java .io. objectinputfilter)。该工具允许指定一个过滤器，该过滤器在反序列化之前应用于数据流。它在类的粒度上运行，允许接受或拒绝某些类。默认接受类并拒绝潜在危险类的列表称为黑名单；在默认情况下拒绝类并接受假定安全的类的列表称为白名单。比起黑名单，更喜欢白名单，因为黑名单只保护你免受已知的威胁。一个名为Serial Whitelist Application Trainer (SWAT)的工具可用于应用程序自动准备一个白名单[Schneider16]。过滤工具还将保护免受过度使用内存和过深的对象图的影响，但它不能保护免受如上面所示的序列化炸弹的影响。
不幸的是，序列化在Java生态系统中仍然普遍存在。 如果要维护基于Java序列化的系统，请认真考虑迁移到跨平台的结构化数据表示，即使这可能是一项耗时的工作。 实际上，可能仍然发现自己必须编写或维护可序列化的类。 编写一个正确，安全，高效的可序列化类需要非常小心。 本章的其余部分提供了有关何时以及如何执行此操作的建议。
总之，序列化是危险的，应该避免。如果从头开始设计一个系统，可以使用跨平台的结构化数据表示，如JSON或protobuf。不要反序列化不受信任的数据。如果必须这样做，请使用对象反序列化过滤器，但要注意，它不能保证阻止所有攻击。避免编写可序列化的类。如果你必须这样做，一定要非常小心。
86. 非常谨慎地实现SERIALIZABLE接口
允许对类的实例进行序列化可以非常简单，只需将implements Serializable添加到类的声明中即可。因为这很容易做到，所以有一个普遍的误解，认为序列化只需要程序员付出很少的努力。事实要复杂得多。虽然使类可序列化的即时成本可以忽略不计，但长期成本通常是巨大的。
实现Serializable的一个主要成本是，一旦类的实现被发布，会降低更改该类实现的灵活性。当类实现Serializable时，其字节流编码(或序列化形式)成为其导出API的一部分。一旦这个类被广泛分发后，通常就需要永远支持序列化形式，就像需要支持导出API的所有其他部分一样。如果不努力设计自定义序列化形式（custom serialized form），而只是接受默认值，则序列化形式将永远绑定到类的原始内部表示上。换句话说，如果接受默认的序列化形式，类的私有和包级私有实例属性将成为其导出API的一部分，并且最小化属性访问的实践(条目 15)也失去其作为信息隐藏工具的有效性。
如果接受默认的序列化形式，日后更改类的内部表示，则会导致序列化形式中的不兼容更改。 尝试使用旧版本的类序列化实例并使用新版本对其进行反序列化（反之亦然）的客户端将遇到程序失败。 可以在保持原始序列化形式（使用ObjectOutputStream.putFields和ObjectInputStream.readFields）的同时更改内部表示，但这可能很困难并且在源代码中留下可见的缺陷。 如果选择将类序列化，应该仔细设计一个愿意长期使用的高质量序列化形式（条目 87，90）。 这样做会增加开发的初始成本，但值得付出努力。 即使是精心设计的序列化形式也会限制一个类的演变; 一个设计不良的序列化形式可能是后果严重的。
限制类的序列化演变的一个简单示例涉及到流的唯一标识符（stream unique identifiers），通常称为序列版本UID（serial version UIDs）。 每个可序列化的类都有一个与之关联的唯一标识号。 如果未通过声明名为serialVersionUID的静态fianl的long类型的来指定此数字，则系统会在运行时通过加密哈希函数（SHA-1）根据类的结构来自动生成它。 此值受类的名称，它实现的接口及其大多数成员（包括编译器生成的组合成（synthetic members）员）的影响。 如果更改任何这些内容，例如，通过添加一个便捷的方法，生成的序列版本UID就会更改。 如果未能声明序列版本UID，则兼容性将被破坏，从而导致运行时出现InvalidClassException异常。
实现Serializable的第二个成本是它增加了错误和安全漏洞的可能性（条目 85）。 通常，使用构造方法创建对象; 序列化是一种语言之外的创建对象的机制。 无论接受默认行为还是重写默认行为，反序列化都是一个“隐藏的构造方法”，与其他构造方法具有相同的问题。 因为没有与反序列化相关联的显式构造方法，所以很容易忘记必须确保它保证构造方法建立的所有不变性，并且它不允许攻击者访问构造中的对象的内部。 依赖于默认的反序列化机制，可以轻松地将对象置于不变性破坏和非法访问之外（第88项）。
实现Serializable的第三个成本是它增加了与发布新版本类相关的测试负担。 修改可序列化类时，重要的是检查是否可以序列化新版本中的实例可以在旧版本中反序列化，反之亦然。 因此，所需的测试量与可序列化类的数量和可能很大的发布数量的乘积成比。 必须确保“序列化——反序列化”过程成功，并确保它生成原始对象的忠实副本。 如果在首次编写类时仔细设计自定义序列化形式，那么测试的需求就会减少（条目 87，90）。
实现Serializable并不是一个轻松的决定。如果一个类要参与依赖于Java序列化来进行对象传输或持久性的框架，那么这一点是非常重要的。此外，它还极大地简化了将类作为必须实现Serializable的另一个类中的组件的使用。然而，与实现Serializable相关的成本很多。每次设计一个类时，都要权衡利弊。历史上，像BigInteger和Instant这样的值类实现了序列化，集合类也实现了Serializable。表示活动实体(如线程池)的类很少实现Serializable。
为继承而设计的类（条目 19）应该很少实现Serializable接口，接口也很少去继承它。 违反此规则会给继承类或实现接口的任何人带来沉重的负担。但是 有时候违反规则是合适的。 例如，如果一个类或接口主要存在于要求所有参与者实现Serializable的框架中，对类或接口来说，实现或继承Serializable是有意义的。
专为实现Serializable的继承而设计的类包括Throwable和Component。 Throwable实现Serializable，因此RMI可以从服务器向客户端发送异常。 Component实现Serializable，因此可以发送，保存和恢复GUI，但即使在Swing和AWT的全盛时期，这种机制在实践中很少使用。
如果实现了具有可序列化和可扩展的实例属性的类，则需要注意几个风险。如果实例属性的值上有任何不变行，关键是要防止子类重写finalize方法，该类可以通过重写finalize方法并声明它为final来实现这一点。否则，该类将容易受到终结器攻击（finalizer attacks）（条目 8）。最后，如果类的实例属性初始化为其默认值（整数类型为零，布尔值为false，对象引用类型为null），则会违反不变性，必须添加readObjectNoData方法：
// readObjectNoData for stateful extendable serializable classes
private void readObjectNoData() throws InvalidObjectException {
throw new InvalidObjectException("Stream data required");
}
在Java 4中添加了此方法，包括向现有可序列化类[Serialization，3.5]添加可序列化父类的极端情况。
关于不实现Serializable接口的决定有一点需要注意。 如果为继承而设计的类，此类不可序列化，则可能需要额外的努力编写可序列化的子类。 这种类的正常反序列化要求父类具有可访问的无参构造方法[Serialization，1.10]。 如果不提供这样的构造方法，则子类被迫使用序列化代理模式（serialization proxy pattern）（条目 90）。
内部类（条目 24）不应实现Serializable。 它们使用编译器生成的合成属性（synthetic fields）来保持对外围实例（enclosing instances）的引用，还保存来自外围作用范围的局部变量的值。这些属性与类定义的对应关系，以及匿名类和本地类的名称都是未指定的。 因此，内部类的默认序列化形式是不明确的。 但是，静态成员类可以实现Serializable。
总而言之，不要认为实现Serializable是简单的事情。除非类只在受保护的环境中使用，在这种环境中，版本永远不必相互操作，服务器永远不会暴露于不受信任的数据，否则实现Serializable是一项严肃的承诺，应该非常谨慎。如果类允许继承，则需要更加格外小心。
87. 考虑使用自定义序列化形式
当在时间紧迫的情况下编写类时，通常应该将精力集中在设计最佳API上。有时这意味着发布一个“一次性使用（throwaway）”实现，将在将来的版本中替换它。通常这不是一个问题，但是如果类实现Serializable并使用默认的序列化形式，将永远无法完全“摆脱一次性使用”的实现了。它永远决定序列化的形式。这不仅仅是一个理论问题。这种情况发生在Java类库中的几个类上，包括BigInteger。
如果没有考虑是否合适，请不要接受默认的序列化形式。 接受默认的序列化形式应该有意识地决定，从灵活性，性能和正确性的角度来看这种编码是合理的。 一般来说，只有在与设计自定义序列化形式时所选择的编码大致相同的情况下，才应接受默认的序列化形式。
对象的默认序列化形式是对象图（object graph）的物理表示形式的一种相当有效的编码，该表示形式以对象为根。换句话说，它描述了对象中包含的数据以及从该对象可以访问的每个对象中的数据。它还描述了所有这些对象相互关联的拓扑结构。理想的对象序列化形式只包含对象所表示的逻辑数据。它独立于物理表示。
如果对象的物理表示与其逻辑内容相同，则默认的序列化形式可能是合适的。例如，默认的序列化形式对于下面的类来说是合理的，它简单地表示一个人的名字:
// Good candidate for default serialized form
public class Name implements Serializable {
/**
* Last name. Must be non-null.
* @serial
*/
private final String lastName;
/**
* First name. Must be non-null.
* @serial
*/
private final String firstName;
/**
* Middle name, or null if there is none.
* @serial
*/
private final String middleName;
... // Remainder omitted
}
从逻辑上讲，名称由三个字符串组成，分别表示姓、名和中间名。名称中的实例属性精确地反映了这个逻辑内容。
即使你确定默认的序列化形式是合适的，通常也必须提供readObject方法以确保不变性和安全性。 对于Name类，readObject方法必须确保属性lastName和firstName为非null。 条目 88和90详细讨论了这个问题。
注意，虽然lastName、firstName和middleName属性是私有的，但是它们都有文档注释。这是因为这些私有属性定义了一个公共API，它是类的序列化形式，并且必须对这个公共API进行文档化。@serial标签的存在告诉Javadoc将此文档放在一个特殊的页面上，该页面记录序列化的形式。
与Name类的另一极端，考虑下面的类，它表示一个字符串列表(暂时忽略使用标准List实现可能更好的建议):
// Awful candidate for default serialized form
public final class StringList implements Serializable {
private int size = 0;
private Entry head = null;
private static class Entry implements Serializable {
String data;
Entry next;
Entry previous;
}
... // Remainder omitted
}
从逻辑上讲，这个类表示字符串序列。在物理上，它将序列表示为双链表。如果接受默认的序列化形式，则序列化形式将煞费苦心地镜像链表中的每个entry，以及每一个entry之间的所有双向链接。
当对象的物理表示与其逻辑数据内容有很大差异时，使用默认的序列化形式有四个缺点:
-
它将导出的API永久绑定到当前类的内部表示。 在上面的示例中，私有
StringList.Entry类成为公共API的一部分。 如果在将来的版本中更改了表示，则StringList类仍需要接受输入上的链表表示，并在输出时生成它。 该类永远不会消除处理链表entry的所有代码，即使不再使用它们。 -
它会消耗过多的空间。 在上面的示例中，序列化形式不必要地表示链接列表中的每个entry和所有链接。 这些entry和链接仅仅是实现细节，不值得包含在序列化形式中。 由于序列化形式过大，将其写入磁盘或通过网络发送将会非常慢。
-
它会消耗过多的时间。 序列化逻辑不了解对象图的拓扑结构，因此必须经历昂贵的图遍历。 在上面的例子中，仅仅遵循下一个引用就足够了。
-
它会导致堆栈溢出。 默认的序列化过程执行对象图的递归遍历，即使对于中等大小的对象图，也可能导致堆栈溢出。 使用1,000-1,800个元素序列化StringList实例，就会在我的机器上生成StackOverflowError异常。 令人惊讶的是，序列化导致堆栈溢出的最小列表大小因运行而异（在我的机器上）。 显示此问题的最小列表大小可能取决于平台实现和命令行标记; 某些实现可能根本没有这个问题。
StringList的合理序列化形式，就是列表中的字符串数量，然后紧跟着字符串本身。这构成了由StringList表示的逻辑数据，去掉了其物理表示的细节。下面是修改后的StringList版本，包含实现此序列化形式的writeObject和readObject方法。提醒一下，transient修饰符表示要从类的默认序列化形式中省略一个实例属性:
// StringList with a reasonable custom serialized form
public final class StringList implements Serializable {
private transient int size = 0;
private transient Entry head = null;
// No longer Serializable!
private static class Entry {
String data;
Entry next;
Entry previous;
}
// Appends the specified string to the list
public final void add(String s) { ... }
/**
* Serialize this {@code StringList} instance.
*
* @serialData The size of the list (the number of strings
* it contains) is emitted ({@code int}), followed by all of
* its elements (each a {@code String}), in the proper
* sequence.
*/
private void writeObject(ObjectOutputStream s)
throws IOException {
s.defaultWriteObject();
s.writeInt(size);
// Write out all elements in the proper order.
for (Entry e = head; e != null; e = e.next)
s.writeObject(e.data);
}
private void readObject(ObjectInputStream s)
throws IOException, ClassNotFoundException {
s.defaultReadObject();
int numElements = s.readInt();
// Read in all elements and insert them in list
for (int i = 0; i < numElements; i++)
add((String) s.readObject());
}
... // Remainder omitted
}
writeObject做的第一件事就是调用defaultWriteObject方法，而readObject做的第一件事就是调用defaultReadObject，即使所有StringList的属性都是瞬时状态（transient）的。 你可能会听到它说如果所有类的实例属性都是瞬时状态的，那么可以省去调用defaultWriteObject和defaultReadObject，但序列化规范要求无论如何都要调用它们。 这些调用的存在使得可以在以后的版本中添加非瞬时状态的实例属性，同时保持向后和向前兼容性。 如果实例在更高版本中序列化，并在早期版本中反序列化，则添加的属性将被忽略。 如果早期版本的readObject方法无法调用defaultReadObject，则反序列化将失败，抛出StreamCorruptedException异常。
请注意，writeObject方法有一个文档注释，即使它是私有的。 这类似于Name类中私有属性的文档注释。 此私有方法定义了一个公共API，它是序列化形式，并且应该记录公共API。 与属性的@serial标签一样，方法的@serialData标签告诉Javadoc实用程序将此文档放在序列化形式的页面上。
为了给前面的性能讨论提供一定的伸缩性，如果平均字符串长度是10个字符，那么经过修改的StringList的序列化形式占用的空间大约是原始字符串序列化形式的一半。在我的机器上，长度为10的列表，序列化修订后的StringList的速度是序列化原始版本的两倍多。最后，在修改后的序列化形式中没有堆栈溢出问题，因此对于可序列化的StringList的大小没有实际的上限。
虽然默认的序列化形式对于StringList来说是不好的，但是对于有些类会可能更糟糕。 对于StringList，默认的序列化形式是不灵活的，并且执行得很糟糕，但是在序列化和反序列化StringList实例，它产生了原始对象的忠实副本，其所有不变性都是完整的。 对于其不变性与特定实现的详细信息相关联的任何对象，情况并非如此。
例如，考虑哈希表（hash table）的情况。它的物理表示是一系列包含键值（key-value）项的哈希桶。每一项所在桶的位置，是其键的散列代码的方法决定的，通常情况下，不能保证从一个实现到另一个实现是相同的。事实上，它甚至不能保证每次运行都是相同的。因此，接受哈希表的默认序列化形式会构成严重的错误。对哈希表进行序列化和反序列化可能会产生一个不变性严重损坏的对象。
无论是否接受默认的序列化形式，当调用defaultWriteObject方法时，没有标记为transient的每个实例属性都会被序列化。因此，可以声明为transient的每个实例属性都应该是。这包括派生（derived）属性，其值可以从主要数据属性（primary data fields）(如缓存的哈希值)计算。它还包括一些属性，这些属性的值与JVM的一个特定运行相关联，比如表示指向本地数据结构指针的long型属性。在决定使非瞬时状态的属性之前，请确信它的值是对象逻辑状态的一部分。如果使用自定义序列化形式，则大多数或所有实例属性都应该标记为transient，如上面的StringList示例所示。
如果使用默认的序列化形式，并且标记了一个或多个属性为transient，请记住，当反序列化实例时，这些属性将初始化为默认值：对象引用属性为null，基本数字类型的属性为0，布尔属性为false [JLS, 4.12.5]。如果这些值对于任何瞬时状态的属性都不可接受，则必须提供一个readObject方法，该方法调用defaultReadObject方法，然后将瞬时状态的属性恢复为可接受的值(条目 88)。或者，这些属性可以在第一次使用时进行延迟初始化（条目 83）。
无论是否使用默认的序列化形式，必须对对象序列化加以同步，也要对读取对象的整个状态的任何方法施加同步。。 因此，例如如果有一个线程安全的对象（条目 82）通过同步每个方法来实现其线程安全，并且选择使用默认的序列化形式，请使用以下write-Object方法：
// writeObject for synchronized class with default serialized form
private synchronized void writeObject(ObjectOutputStream s)
throws IOException {
s.defaultWriteObject();
}
如果将同步放在writeObject方法中，则必须确保它遵守与其他活动相同的锁排序( lock-ordering)约束，否则将面临资源排(resource-ordering)序死锁的风险[Goetz06, 10.1.5]。
无论选择哪种序列化形式，都要在编写的每个可序列化类中声明显式的序列版本UID。这消除了序列版本UID作为不兼容性的潜在来源(条目 86)。还有一个小的性能优势。如果没有提供序列版本UID，则需要执行昂贵的计算来在运行时生成一个UID。
声明序列版本UID很简单。只需要在类中添加这一行:
private static final long serialVersionUID = randomLongValue;
如编写一个新类，为randomLongValue选择什么值并不重要。可以通过在类上运行serialver实用程序来生成该值，但是也可以凭空选择一个数字。序列版本UID不需要是惟一的。如果修改缺少序列版本UID的现有类，并且希望新版本接受现有的序列化实例，则必须使用为旧版本自动生成的值。可以通过在类的旧版本上运行serialver实用程序(序列化实例存在于旧版本上)来获得这个数字。
如果想要创建与现有版本不兼容的类的新版本，只需更改序列版本UID声明中的值即可。 这将导致尝试反序列化先前版本的序列化实例抛出InvalidClassException异常。 不要更改序列版本UID，除非想破坏与类的所有现有序列化实例的兼容性。
总而言之，如果你已确定某个类应该可序列化（条目 86），请仔细考虑序列化形式应该是什么。 仅当它是对象逻辑状态的合理描述时，才使用默认的序列化形式；否则设计一个适当描述对象的自定义序列化形式。 在分配设计导出方法时，应该分配尽可能多的时间来设计类的序列化形式（条目 51）。 正如无法从将来的版本中删除导出的方法一样，也无法从序列化形式中删除属性；必须永久保存它们以确保序列化兼容性。 选择错误的序列化形式会对类的复杂性和性能产生永久性的负面影响。
88. 防御性地编写READOBJECT方法
条目 50 里有一个不可变的日期范围类，它包含一个可变的私有Date属性。 该类通过在其构造方法和访问器中防御性地拷贝Date对象，竭尽全力维持其不变性（invariants and immutability）。 代码如下所示：
// Immutable class that uses defensive copying
public final class Period {
private final Date start;
private final Date end;
/**
* @param start the beginning of the period
* @param end the end of the period; must not precede start
* @throws IllegalArgumentException if start is after end
* @throws NullPointerException if start or end is null
*/
public Period(Date start, Date end) {
this.start = new Date(start.getTime());
this.end = new Date(end.getTime());
if (this.start.compareTo(this.end) > 0)
throw new IllegalArgumentException(
start + " after " + end);
}
public Date start () { return new Date(start.getTime()); }
public Date end () { return new Date(end.getTime()); }
public String toString() { return start + " - " + end; }
... // Remainder omitted
}
假设要把这个类可序列化。由于Period对象的物理表示精确地反映了它的逻辑数据内容，所以使用默认的序列化形式是合理的(条目 87)。因此，要使类可序列化，似乎只需将implements Serializable 添加到类声明中就可以了。但是，如果这样做，该类不再保证它的关键不变性了。
问题是readObject方法实际上是另一个公共构造方法，它需要与任何其他构造方法一样的小心警惕。 正如构造方法必须检查其参数的有效性（条目 49）并在适当的地方对参数防御性拷贝（条目 50），readObject方法也要这样做。 如果readObject方法无法执行这两个操作中的任何一个，则攻击者违反类的不变性是相对简单的事情。
简而言之，readObject是一个构造方法，它将字节流作为唯一参数。 在正常使用中，字节流是通过序列化正常构造的实例生成的。当readObject展现一个字节流时，问题就出现了，这个字节流是人为构造的，用来生成一个违反类不变性的对象。 这样的字节流可用于创建一个不可能的对象，该对象无法使用普通构造方法创建。
假设我们只是将implements Serializablet添加到Period类声明中。 然后，这个丑陋的程序生成一个Period实例，其结束时间在其开始时间之前。 对byte类型的值进行强制转换，其高阶位被设置，这是由于Java缺乏byte字面量，并且错误地决定对byte类型进行签名:
public class BogusPeriod {
// Byte stream couldn't have come from a real Period instance!
private static final byte[] serializedForm = {
(byte)0xac, (byte)0xed, 0x00, 0x05, 0x73, 0x72, 0x00, 0x06,
0x50, 0x65, 0x72, 0x69, 0x6f, 0x64, 0x40, 0x7e, (byte)0xf8,
0x2b, 0x4f, 0x46, (byte)0xc0, (byte)0xf4, 0x02, 0x00, 0x02,
0x4c, 0x00, 0x03, 0x65, 0x6e, 0x64, 0x74, 0x00, 0x10, 0x4c,
0x6a, 0x61, 0x76, 0x61, 0x2f, 0x75, 0x74, 0x69, 0x6c, 0x2f,
0x44, 0x61, 0x74, 0x65, 0x3b, 0x4c, 0x00, 0x05, 0x73, 0x74,
0x61, 0x72, 0x74, 0x71, 0x00, 0x7e, 0x00, 0x01, 0x78, 0x70,
0x73, 0x72, 0x00, 0x0e, 0x6a, 0x61, 0x76, 0x61, 0x2e, 0x75,
0x74, 0x69, 0x6c, 0x2e, 0x44, 0x61, 0x74, 0x65, 0x68, 0x6a,
(byte)0x81, 0x01, 0x4b, 0x59, 0x74, 0x19, 0x03, 0x00, 0x00,
0x78, 0x70, 0x77, 0x08, 0x00, 0x00, 0x00, 0x66, (byte)0xdf,
0x6e, 0x1e, 0x00, 0x78, 0x73, 0x71, 0x00, 0x7e, 0x00, 0x03,
0x77, 0x08, 0x00, 0x00, 0x00, (byte)0xd5, 0x17, 0x69, 0x22,
0x00, 0x78
};
public static void main(String[] args) {
Period p = (Period) deserialize(serializedForm);
System.out.println(p);
}
// Returns the object with the specified serialized form
static Object deserialize(byte[] sf) {
try {
return new ObjectInputStream(
new ByteArrayInputStream(sf)).readObject();
} catch (IOException | ClassNotFoundException e) {
throw new IllegalArgumentException(e);
}
}
}
用于初始化serializedForm的字节数组字面量（literal）是通过序列化正常的Period实例，并手动编辑生成的字节流生成的。 流的细节对于该示例并不重要，但是如果好奇，则在《Java Object Serialization Specification》[序列化，6]中描述了序列化字节流格式。 如果运行此程序，它会打印Fri Jan 01 12:00:00 PST 1999 - Sun Jan 01 12:00:00 PST 1984。只需声明Period类为可序列化，我们就可以创建一个违反其类不变性的对象。
要解决此问题，请为Period提供一个readObject方法，该方法调用defaultReadObject，然后检查反序列化对象的有效性。如果有效性检查失败，readObject方法抛出InvalidObjectException异常，阻止反序列化完成:
// readObject method with validity checking - insufficient!
private void readObject(ObjectInputStream s)
throws IOException, ClassNotFoundException {
s.defaultReadObject();
// Check that our invariants are satisfied
if (start.compareTo(end) > 0)
throw new InvalidObjectException(start +" after "+ end);
}
虽然这样可以防止攻击者创建无效的Period实例，但仍然存在潜在的更微妙的问题。 可以通过构造以有效Period实例开头的字节流来创建可变Period实例，然后将额外引用附加到Period实例内部的私有Date属性。 攻击者从ObjectInputStream中读取Period实例，然后读取附加到流的“恶意对象引用”。 这些引用使攻击者可以访问Period对象中私有Date属性引用的对象。 通过改变这些Date实例，攻击者可以改变Period实例。 以下类演示了这种攻击：
public class MutablePeriod {
// A period instance
public final Period period;
// period's start field, to which we shouldn't have access
public final Date start;
// period's end field, to which we shouldn't have access
public final Date end;
public MutablePeriod() {
try {
ByteArrayOutputStream bos =
new ByteArrayOutputStream();
ObjectOutputStream out =
new ObjectOutputStream(bos);
// Serialize a valid Period instance
out.writeObject(new Period(new Date(), new Date()));
/*
* Append rogue "previous object refs" for internal
* Date fields in Period. For details, see "Java
* Object Serialization Specification," Section 6.4.
*/
byte[] ref = { 0x71, 0, 0x7e, 0, 5 }; // Ref #5
bos.write(ref); // The start field
ref[4] = 4; // Ref # 4
bos.write(ref); // The end field
// Deserialize Period and "stolen" Date references
ObjectInputStream in = new ObjectInputStream(
new ByteArrayInputStream(bos.toByteArray()));
period = (Period) in.readObject();
start = (Date) in.readObject();
end = (Date) in.readObject();
} catch (IOException | ClassNotFoundException e) {
throw new AssertionError(e);
}
}
}
要查看正在进行的攻击，请运行以下程序：
public static void main(String[] args) {
MutablePeriod mp = new MutablePeriod();
Period p = mp.period;
Date pEnd = mp.end;
// Let's turn back the clock
pEnd.setYear(78);
System.out.println(p);
// Bring back the 60s!
pEnd.setYear(69);
System.out.println(p);
}
在我的语言环境中，运行此程序会产生以下输出：
Wed Nov 22 00:21:29 PST 2017 - Wed Nov 22 00:21:29 PST 1978
Wed Nov 22 00:21:29 PST 2017 - Sat Nov 22 00:21:29 PST 1969
虽然创建了Period实例且保持了其不变性，但可以随意修改其内部组件。 一旦拥有可变的Period实例，攻击者可能会通过将实例传递给依赖于Period的安全性不变性的类来造成巨大的伤害。 这并非如此牵强：有些类就是依赖于String的不变性来保证安全性的。
问题的根源是Period类的readObject方法没有做足够的防御性拷贝。 对象反序列化时，防御性地拷贝包含客户端不能拥有的对象引用的属性，是至关重要的。 因此，每个包含私有可变组件的可序列化不可变类，必须在其readObject方法中防御性地拷贝这些组件。 以下readObject方法足以确保Period的不变性并保持其不变性：
// readObject method with defensive copying and validity checking
private void readObject(ObjectInputStream s)
throws IOException, ClassNotFoundException {
s.defaultReadObject();
// Defensively copy our mutable components
start = new Date(start.getTime());
end = new Date(end.getTime());
// Check that our invariants are satisfied
if (start.compareTo(end) > 0)
throw new InvalidObjectException(start +" after "+ end);
}
请注意，防御性拷贝在有效性检查之前执行，并且我们没有使用Date的clone方法来执行防御性拷贝。 需要这两个细节来保护Period免受攻击（条目 50）。 另请注意，final属性无法进行防御性拷贝。 要使用readObject方法，我们必须使start和end属性不能是final类型的。 这是不幸的，但它是这两个中较好的一个做法。 使用新的readObject方法并从start和end属性中删除final修饰符后，MutablePeriod类不再无效。 上面的攻击程序现在生成如下输出：
Wed Nov 22 00:23:41 PST 2017 - Wed Nov 22 00:23:41 PST 2017
Wed Nov 22 00:23:41 PST 2017 - Wed Nov 22 00:23:41 PST 2017
下面是一个简单的石蕊测试(litmus test)，用于确定类的默认readObject方法是否可接受：你是否愿意添加一个公共构造方法，该构造方法把对象中每个非瞬时状态的属性值作为参数，并在没有任何验证的情况下，将值保存在属性中？如果没有，则必须提供readObject方法，并且它必须执行构造方法所需的所有有效性检查和防御性拷贝。或者，可以使用序列化代理模式（serialization proxy pattern））(条目 90)。强烈推荐使用这种模式，因为它在安全反序列化方面花费了大量精力。
readObject方法和构造方法还有一个相似之处，它们适用于非final可序列化类。 与构造方法一样，readObject方法不能直接或间接调用可重写的方法（条目 19）。 如果违反此规则并且重写了相关方法，则重写方法会在子类状态被反序列化之前运行。 程序可能会导致失败[Bloch05，Puzzle 91]。
总而言之，无论何时编写readObject方法，都要采用这样一种思维方式，即正在编写一个公共构造方法，该构造方法必须生成一个有效的实例，而不管给定的是什么字节流。不要假设字节流一定表示实际的序列化实例。虽然本条目中的示例涉及使用默认序列化形式的类，但是所引发的所有问题都同样适用于具有自定义序列化形式的类。下面是编写readObject方法的指导原则:
-
对于具有必须保持私有的对象引用属性的类，防御性地拷贝该属性中的每个对象。不可变类的可变组件属于这一类别。
-
检查任何不变性，如果检查失败，则抛出InvalidObjectException异常。 检查应再任何防御性拷贝之后。
-
如果必须在反序列化后验证整个对象图（object graph），那么使用ObjectInputValidation接口(在本书中没有讨论)。
-
不要直接或间接调用类中任何可重写的方法。
89. 对于实例控制，枚举类型优于READRESOLVE
条目 3描述了单例（Singleton）模式，并给出了以下示例的单例类。 此类限制对其构造方法的访问，以确保只创建一个实例：
public class Elvis {
public static final Elvis INSTANCE = new Elvis();
private Elvis() { ... }
public void leaveTheBuilding() { ... }
}
如条目 3所述，如果将implements Serializable添加到类的声明中，则此类将不再是单例。 类是否使用默认的序列化形式或自定义序列化形式（条目 87）并不重要，该类是否提供显式的readObject方法（条目 88项）也无关紧要。 任何readObject方法，无论是显式方法还是默认方法，都会返回一个新创建的实例，该实例与在类初始化时创建的实例不同。
readResolve特性允许你用另一个实例替换readObject方法 [Serialization, 3.7]创建的实例。如果正在反序列化的对象的类，使用正确的声明定义了readResolve方法，则在新创建的对象反序列化之后，将在该对象上调用该方法。该方法返回的对象引用，代替新创建的对象返回。在该特性的大多数使用中，不保留对新创建对象的引用，因此它立即就有资格进行垃圾收集。
如果Elvis类用于实现Serializable，则以下read-Resolve方法足以保证单例性质：
// readResolve for instance control - you can do better!
private Object readResolve() {
// Return the one true Elvis and let the garbage collector
// take care of the Elvis impersonator.
return INSTANCE;
}
此方法忽略反序列化对象，返回初始化类时创建的区分的Elvis实例。因此，Elvis实例的序列化形式不需要包含任何实际数据；所有实例属性都应该声明为transient。事实上，如果依赖readResolve方法进行实例控制，那么所有具有对象引用类型的实例属性都必须声明为transient。否则，有决心的攻击者有可能在运行readResolve方法之前，保护对反序列化对象的引用，使用的技术有点类似于条目 88中的MutablePeriod类攻击。
这种攻击有点复杂，但其基本思想很简单。如果单例包含一个非瞬时状态对象引用属性，则在运行单例的readResolve方法之前，将对该属性的内容进行反序列化。这允许一个精心设计的流在对象引用属性的内容被反序列化时，“窃取”对原来反序列化的单例对象的引用。
下面是它的工作原理。首先，编写一个stealer类，该类具有readResolve方法和一个实例属性，该实例属性引用序列化的单例，其中stealer“隐藏”在其中。在序列化流中，用一个stealer实例替换单例的非瞬时状态属性。现在有了一个循环：单例包含了stealer，而stealer又引用了单例。
因为单例包含stealer，所以当反序列化单例时，stealer的readResolve方法首先运行。因此，当stealer的readResolve方法运行时，它的实例属性仍然引用部分反序列化(且尚未解析)的单例。
stealer的readResolve方法将引用从其实例属性复制到静态属性，以便在readResolve方法运行后访问引用。然后，该方法为其隐藏的属性返回正确类型的值。如果不这样做，当序列化系统试图将stealer引用存储到该属性时，虚拟机会抛出ClassCastException异常。
要使其具体化，请考虑以下有问题的单例:
// Broken singleton - has nontransient object reference field!
public class Elvis implements Serializable {
public static final Elvis INSTANCE = new Elvis();
private Elvis() { }
private String[] favoriteSongs =
{ "Hound Dog", "Heartbreak Hotel" };
public void printFavorites() {
System.out.println(Arrays.toString(favoriteSongs));
}
private Object readResolve() {
return INSTANCE;
}
}
下面是一个“stealer”类，按照上面的描述构造：
public class ElvisStealer implements Serializable {
static Elvis impersonator;
private Elvis payload;
private Object readResolve() {
// Save a reference to the "unresolved" Elvis instance
impersonator = payload;
// Return object of correct type for favoriteSongs field
return new String[] { "A Fool Such as I" };
}
private static final long serialVersionUID = 0;
}
最后，这是一个丑陋的程序，它反序列化了一个手工制作的流，生成有缺陷单例的两个不同实例。这个程序省略了反序列化方法，因为它与条目88（第354页）的方法相同:
public class ElvisImpersonator {
// Byte stream couldn't have come from a real Elvis instance!
private static final byte[] serializedForm = {
(byte)0xac, (byte)0xed, 0x00, 0x05, 0x73, 0x72, 0x00, 0x05,
0x45, 0x6c, 0x76, 0x69, 0x73, (byte)0x84, (byte)0xe6,
(byte)0x93, 0x33, (byte)0xc3, (byte)0xf4, (byte)0x8b,
0x32, 0x02, 0x00, 0x01, 0x4c, 0x00, 0x0d, 0x66, 0x61, 0x76,
0x6f, 0x72, 0x69, 0x74, 0x65, 0x53, 0x6f, 0x6e, 0x67, 0x73,
0x74, 0x00, 0x12, 0x4c, 0x6a, 0x61, 0x76, 0x61, 0x2f, 0x6c,
0x61, 0x6e, 0x67, 0x2f, 0x4f, 0x62, 0x6a, 0x65, 0x63, 0x74,
0x3b, 0x78, 0x70, 0x73, 0x72, 0x00, 0x0c, 0x45, 0x6c, 0x76,
0x69, 0x73, 0x53, 0x74, 0x65, 0x61, 0x6c, 0x65, 0x72, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x01,
0x4c, 0x00, 0x07, 0x70, 0x61, 0x79, 0x6c, 0x6f, 0x61, 0x64,
0x74, 0x00, 0x07, 0x4c, 0x45, 0x6c, 0x76, 0x69, 0x73, 0x3b,
0x78, 0x70, 0x71, 0x00, 0x7e, 0x00, 0x02
};
public static void main(String[] args) {
// Initializes ElvisStealer.impersonator and returns
// the real Elvis (which is Elvis.INSTANCE)
Elvis elvis = (Elvis) deserialize(serializedForm);
Elvis impersonator = ElvisStealer.impersonator;
elvis.printFavorites();
impersonator.printFavorites();
}
}
运行此程序将生成以下输出，最终证明可以创建两个不同的Elvis实例(两种具有不同的音乐品味):
[Hound Dog, Heartbreak Hotel]
[A Fool Such as I]
可以通过声明favoriteSongs属性为transient来解决问题，但最好通过把Elvis成为单个元素枚举类型来修复它（条目 3）。 正如ElvisStealer类攻击所证明的那样，使用readResolve方法来防止攻击者访问“临时”反序列化实例是非常脆弱的，需要非常小心。
如果将可序列化的实例控制类编写为枚举，Java会保证除了声明的常量之外，不会再有有任何实例，除非攻击者滥用AccessibleObject.setAccessible等特权方法。 任何能够做到这一点的攻击者已经拥有足够的权限来执行任意本机代码，并且所有的赌注都已关闭。 以下是下面是Elvis作为枚举的例子:
// Enum singleton - the preferred approach
public enum Elvis {
INSTANCE;
private String[] favoriteSongs =
{ "Hound Dog", "Heartbreak Hotel" };
public void printFavorites() {
System.out.println(Arrays.toString(favoriteSongs));
}
}
使用readResolve进行实例控制并不是过时的。 如果必须编写一个可序列化的实例控制类，实例在编译时是未知的，那么无法将该类表示为枚举类型。
readResolve的可访问性非常重要。 如果在final类上放置readResolve方法，它应该是私有的。 如果将readResolve方法放在非final类上，则必须仔细考虑其可访问性。 如果它是私有的，则不适用于任何子类。 如果它是包级私有的，它将仅适用于同一包中的子类。 如果它是受保护的或公共的，它将适用于所有不重写它的子类。 如果readResolve方法是受保护或公共访问，并且子类不重写它，则反序列化子类实例将生成一个父类实例，这可能会导致ClassCastException异常。
总而言之，使用枚举类型尽可能强制实例控制不变性。 如果这是不可能的，并且还需要一个类可序列化和实例控制，则必须提供readResolve方法并确保所有类的实例属性都是基本类型，或瞬时状态。
90. 考虑序列化代理替代序列化实例
正如在条目 85和 条目86中提到并贯穿本章的讨论，实现Serializable接口的决定，增加了出现bug和安全问题的可能性，因为它允许使用一种语言之外的机制来创建实例，而不是使用普通的构造方法。然而，有一种技术可以大大降低这些风险。这种技术称为序列化代理模式（serialization proxy pattern）。
序列化代理模式相当简单。首先，设计一个私有静态嵌套类，它简洁地表示外围类实例的逻辑状态。这个嵌套类称为外围类的序列化代理。它应该有一个构造方法，其参数类型是外围类。这个构造方法只是从它的参数拷贝数据：它不需要做任何一致性检查或防御性拷贝。按照设计，序列化代理的默认序列化形式是外围类的最好的序列化形式。外围类及其序列化代理都必须声明以实现Serializable。
例如，考虑在条目 50中编写的不可变Period类，并在条目 88中进行序列化。以下是该类的序列化代理。 Period非常简单，其序列化代理与该属性具有完全相同的属性：
// Serialization proxy for Period class
private static class SerializationProxy implements Serializable {
private final Date start;
private final Date end;
SerializationProxy(Period p) {
this.start = p.start;
this.end = p.end;
}
private static final long serialVersionUID =
234098243823485285L; // Any number will do (Item 87)
}
接下来，将以下writeReplace方法添加到外围类中。可以将此方法逐字复制到具有序列化代理的任何类中：
// writeReplace method for the serialization proxy pattern
private Object writeReplace() {
return new SerializationProxy(this);
}
该方法在外围类上的存在，导致序列化系统发出SerializationProxy实例，而不是外围类的实例。换句话说，writeReplace方法在序列化之前将外围类的实例转换为它的序列化代理。
使用此writeReplace方法，序列化系统永远不会生成外围类的序列化实例，但攻击者可能会构造一个实例，试图违反类的不变性。 要确保此类攻击失败，只需把readObject方法添加到外围类中：
// readObject method for the serialization proxy pattern
private void readObject(ObjectInputStream stream)
throws InvalidObjectException {
throw new InvalidObjectException("Proxy required");
}
最后，在SerializationProxy类上提供一个readResolve方法，该方法返回外围类逻辑等效的实例。此方法的存在导致序列化系统在反序列化时把序列化代理转换回外围类的实例。
这个readResolve方法只使用其公共API创建了一个外围类的实例，这就是该模式的美妙之处。它在很大程度上消除了序列化的语言外特性，因为反序列化实例是使用与任何其他实例相同的构造方法、静态工厂和方法创建的。这使你不必单独确保反序列化的实例遵从类的不变量。如果类的静态工厂或构造方法确立了这些不变性，而它的实例方法维护它们，那么就确保了这些不变性也将通过序列化来维护。
以下是Period.SerializationProxy的readResolve方法：
// readResolve method for Period.SerializationProxy
private Object readResolve() {
return new Period(start, end); // Uses public constructor
}
与防御性拷贝方法（第357页）一样，序列化代理方法可以阻止伪造的字节流攻击（条目 88，第354页）和内部属性盗用攻击（条目 88， 第356页）。 与前两种方法不同，这一方法允许Period类的属性为final，这是Period类成为真正不可变所必需的（条目 17）。 与之前的两种方法不同，这个方法并没有涉及很多想法。 不你必弄清楚哪些属性可能会被狡猾的序列化攻击所破坏，也不必显示地进行有效性检查，作为反序列化的一部分。
还有另一种方法，序列化代理模式比readObject中的防御性拷贝更为强大。 序列化代理模式允许反序列化实例具有与最初序列化实例不同的类。 你可能认为这在实践中没有有用，但并非如此。
考虑EnumSet类的情况（条目 36）。 这个类没有公共构造方法，只有静态工厂。 从客户端的角度来看，它们返回EnumSet实例，但在当前的OpenJDK实现中，它们返回两个子类中的一个，具体取决于底层枚举类型的大小。 如果底层枚举类型包含64个或更少的元素，则静态工厂返回RegularEnumSet; 否则，他们返回一个JumboEnumSet。
现在考虑，如果你序列化一个枚举集合，集合枚举类型有60个元素，然后将五个元素添加到这个枚举类型，再反序列化枚举集合。序列化时，这是一个RegularEnumSet实例，但一旦反序列化，最好是JumboEnumSet实例。事实上正是这样，因为EnumSet使用序列化代理模式。如果好奇，如下是EnumSet的序列化代理。其实很简单:
// EnumSet's serialization proxy
private static class SerializationProxy <E extends Enum<E>>
implements Serializable {
// The element type of this enum set.
private final Class<E> elementType;
// The elements contained in this enum set.
private final Enum<?>[] elements;
SerializationProxy(EnumSet<E> set) {
elementType = set.elementType;
elements = set.toArray(new Enum<?>[0]);
}
private Object readResolve() {
EnumSet<E> result = EnumSet.noneOf(elementType);
for (Enum<?> e : elements)
result.add((E)e);
return result;
}
private static final long serialVersionUID =
362491234563181265L;
}
序列化代理模式有两个限制。它与用户可扩展的类不兼容(条目 19)。而且，它与一些对象图包含循环的类不兼容：如果试图从对象的序列化代理的readResolve方法中调用对象上的方法，得到一个ClassCastException异常，因为你还没有对象，只有该对象的序列化代理。
最后，序列化代理模式增强的功能和安全性并不是免费的。 在我的机器上，使用序列化代理序列化和反序列化Period实例，比使用防御性拷贝多出14％的昂贵开销。
总之，只要发现自己必须在不能由客户端扩展的类上编写readObject或writeObject方法时，请考虑序列化代理模式。 使用重要不变性来健壮序列化对象时，这种模式可能是最简单方法。
