java 单例模板_[代码模板]-创建型-单例-闲的蛋疼破坏单例

在正常代码编码中，一个单例写完之后，在某个特定场景下，这个类就只有唯一的一个实例，比如：在一个 Java 进程中，或者在一个容器中。

但是单例仍然可以通过非常规的操作进行破坏，比如：反射、序列化反序列化，

不过正常情况下的代码编写，也不会有人特意去这么做，正常都是闲的蛋疼。

反射、序列化反序列化之所以能够破坏单例，本质上都是绕过了私有构造，使用反射 API 实例化出了新的对象。

下面分别来看一下这两种破坏单例的实现，以及如何解决这种问题。

首先准备一个单例实现，静态内部类的懒加载单例实现，该单例用以演示破坏和解决单例的问题，相关代码如下：

反射破坏单例

通过反射破坏单例，相关代码如下：

如上图所示，单例破坏是通过反射机制绕过安全检查，直接调用私有构造进行实例化的创建，从而导致出现多个实例，破坏单一实例的效果。

而要解决该问题，就需要在私有构造器里面做文章，拒绝反射调用私有构造器。

防止反射进行对象的构造操作关优化单例实现如下：

反序列化破坏单例

单例类需实现 `Serializable`

反序列化破坏单例的相关测试代码如下：

上述代码，通过序列化反序列化操作，也就是将数据转成流倒腾了一遍，从而破坏了单一实例。

下面来看一下 反序列化 破坏单例的原理。

通过 `ObjectInputStream` 源码进行查看，相关源码追踪时序图如下：

来看一下 `ObjectInputStream#readOrdinaryObject` 相关代码实现

通过源码能够知道，反序列化同样是使用的反射来进行对象的实例化。

除了通过构造函数来解决还有什么解决方案？

我们再回到上述源码中，如下：

在反射调用构造函数实例化对象后，会尝试调用类中的 `readResolve` 方法，如果该方法返回对象，就使用该对象返回的对象进行返回。

这时候就可以以这个方法为切入点，来解决反序列化对象不是单例的问题，相关实现代码如下：

在上述代码中，反序列化代码仍然会调用反射构造API 进行对象的构造，但是在返回对象前，通过 `readResolve` 返回已经实例化的对象，保证当前运行环境中对象的单例不被破坏。

End