序列化代理模式

在上一篇文章中，我谈到了一般的序列化。这是更加集中的内容，并提供了一个细节： 序列化代理模式 。这是处理序列化许多问题的一种好方法，通常是最好的方法。如果开发人员只想了解有关该主题的一件事，我会告诉他。

总览

这篇文章的重点是在给出两个简短的例子之前，先介绍模式的详细定义，最后讨论其优缺点。

据我所知，该模式首先在约书亚·布洛赫（Joshua Bloch）的绝妙著作《有效的Java》（第1版：第57项；第2版：第78项）中定义。这篇文章主要重申了那里的说法。

本文中使用的代码示例来自我在GitHub上创建的一个演示项目。查看更多详细信息！

序列化代理模式

此模式应用于单个类，并定义其序列化机制。为了更容易阅读，以下文本将分别将该类或其实例称为原始一个或多个。

序列化代理

顾名思义，模式的关键是序列化代理 。它被写入字节流，而不是原始实例。反序列化之后，它将创建原始类的实例，该类将在对象图中取代。

序列化代理模式

目的是设计代理，使其成为原始类的最佳逻辑表示形式。

实作

SerializationProxy是原始类的静态嵌套类。它的所有字段均为final，唯一的构造函数将原始实例作为唯一的参数。它提取该实例状态的逻辑表示并将其分配给自己的字段。由于原始实例被认为是“安全的”，因此无需进行一致性检查或防御性复制。

原始类和代理类都实现Serializable。但是由于前者实际上从未写入流中，因此只有后者需要一个流唯一标识符 （通常称为串行版本UID ）。

序列化

当要对原始实例进行序列化时，可以通知序列化系统将代理写入字节流。为此，原始类必须实现以下方法：

用代理替换原始实例

private Object writeReplace() {return new SerializationProxy(this);
}

反序列化

在反序列化时，必须反转从原始实例到代理实例的转换。这是通过SerializationProxy中的以下方法实现的，该方法在代理实例成功反SerializationProxy后调用：

将代理转换回原始实例

private Object readResolve() {// create an instance of the original class// in the state defined by the proxy's fields
}

创建原始类的实例将通过其常规API（例如，构造函数）完成。

人工字节流

由于writeReplace常规字节流将仅包含代理的编码。但是对于人工流却并非如此！它们可以包含原始实例的编码，并且由于反序列化这些序列未包括在模式中，因此它无法为该实例提供任何保护措施。

实际上，对此类实例进行反序列化实际上是不需要的，必须防止。这可以通过让原始类中的方法（在这种情况下被调用）抛出异常来完成：

防止直接反序列化原始实例

private void readObject(ObjectInputStream stream) throws InvalidObjectException {throw new InvalidObjectException("Proxy required.");
}

例子

以下示例是完整演示项目的摘录。它们仅显示多汁的部分，而忽略了一些细节（例如writeReplace和readObject ）。

复数

一种简单的情况是复数的一种不变类型，称为ComplexNumber （惊奇！）。出于本示例的考虑，它在其字段中存储了坐标以及极坐标形式（据说是出于性能方面的考虑）：

ComplexNumber –字段

private final double real;
private final double imaginary;
private final double magnitude;
private final double angle;

序列化代理看起来像这样：

ComplexNumber.SerializationProxy

private static class SerializationProxy implements Serializable {private final double real;private final double imaginary;public SerializationProxy(ComplexNumber complexNumber) {this.real = complexNumber.real;this.imaginary = complexNumber.imaginary;}/*** After the proxy is deserialized, it invokes a static factory method* to create a 'ComplexNumber' "the regular way".*/private Object readResolve() {return ComplexNumber.fromCoordinates(real, imaginary);}
}

可以看出，代理不存储极坐标形式的值。原因是它应该捕获最佳的逻辑表示。而且，由于只需要一对值（坐标或极坐标形式）即可创建另一个，因此只能序列化一个。这样可以防止存储两个对以实现更好的性能的实现细节通过序列化泄漏到公共API中。

请注意，原始类以及代理中的所有字段均为最终字段。还要注意静态工厂方法的调用，从而无需进行任何附加的有效性检查。

实例缓存

InstanceCache是一个异构类型安全的容器，它使用从类到其实例的映射作为后备数据结构：

InstanceCache –字段

private final ConcurrentMap<Class<?>, Object> cacheMap;

由于映射可以包含任意类型，因此并非所有映射都必须可序列化。该类的合同规定，足以存储可序列化的类。因此，有必要过滤地图。代理的优点是它是所有此类代码的单点：

InstanceCache.SerializationProxy

private static class SerializationProxy implements Serializable {// array lists are serializableprivate final ArrayList<Serializable> serializableInstances;public SerializationProxy(InstanceCache cache) {serializableInstances = extractSerializableValues(cache);}private static ArrayList<Serializable> extractSerializableValues(InstanceCache cache) {return cache.cacheMap.values().stream().filter(instance -> instance instanceof Serializable).map(instance -> (Serializable) instance).collect(Collectors.toCollection(ArrayList::new));}/*** After the proxy is deserialized, it invokes a constructor to create* an 'InstanceCache' "the regular way".*/private Object readResolve() {return new InstanceCache(serializableInstances);}}

利弊

序列化代理模式减轻了序列化系统的许多问题。在大多数情况下，这是实现序列化的最佳选择，并且应该是实现序列化的默认方法。

优点

这些是优点：

语外特征减少

该模式的主要优点是它减少了序列化的语言外特征。这主要是通过使用类的公共API创建实例来实现的（请参见上面的SerializationProxy.readResolve ）。因此，每次创建实例都要经过构造函数，并且始终会执行正确初始化实例所需的所有代码。

这也意味着在反序列化期间不必显式调用此类代码，这可以防止其重复。

对最终字段没有限制

由于反序列化实例是在其构造函数中初始化的，因此该方法并不限制哪些字段可以是最终字段（通常是使用自定义序列化形式的情况）。

灵活的实例化

实际上，代理的readResolve不必返回与序列化类型相同的实例。它也可以返回任何子类。

Bloch给出以下示例：

考虑EnumSet的情况。此类没有公共构造函数，只有静态工厂。从客户端的角度来看，它们返回EnumSet实例，实际上，它们返回两个子类之一，具体取决于基础枚举类型的大小。如果基础枚举类型具有64个或更少的元素，则静态工厂将返回RegularEnumSet ; 否则，它们返回JumboEnumSet 。

现在考虑一下，如果序列化其枚举类型具有60个元素的枚举集，然后向该枚举类型添加另外五个元素，然后反序列化该枚举集，会发生什么情况。序列化时它是一个RegularEnumSet实例，但反序列化后最好是JumboEnumSet实例。

有效的Java，第二版：p。 314

代理模式使这个琐碎的事情变得很简单： readResolve仅返回匹配类型的实例。（这仅在类型符合Liskov替换原理的情况下有效。）