一个单例还能写出花来吗？

小灰灰 2023-01-13 09:10 155阅读 0赞

单例可以说是最简单的一个设计模式了，单例模式要求只能创建一个对象实例。通常的写法是声明私有的构造函数，提供静态方法获取单例的对象实例。

常见的单例写法就是饿汉式、懒汉式、双重加锁验证、静态内部类和枚举的方式，写法可能大家都知道，不过针对不同的写法还是有可以继续深挖一下的地方，让我们从最简单的几种写法开始回顾单例，不想看前面的话直接往后翻好了。

# 回顾几种实现方式 #

### 饿汉式 ###

饿汉式的写法通常静态成员变量已经是初始化好的，优点是可以不加锁就获取到对象实例，线程安全，主要的缺点在于不是延加载，稍微存在内存的浪费，因为如果初始化的逻辑较为复杂，比如存在网络请求或者一些复杂的逻辑在内，就会产生内存的浪费。

![bb96b16bb34f3b8e27fa22f15750c6a2.png][]

### 懒汉式 ###

懒汉式的写法解决了饿汉式浪费内存的问题，在真正需要获取实例对象的才去执行初始化。

通常一般来说可能会有两种方式，第一种就是不加锁的写法，很显然这样是肯定不行的，正常的方式一般都是通过同步锁的方式加锁获取实例对象。

但是这种实现方式在之前的JDK版本`synchronized`没有锁优化的情况每次获取单例对象性能存在很大的问题，于是乎有了DCL的写法。

![f23b0ec2191547bdc0f5d224b57b8110.png][]

### 双重加锁验证DCL ###

于是为了解决懒汉式性能的问题，双重加锁验证的写法诞生了，先判断一次空，真的为空再执行加锁，然后再判断一次。

这样的话，只有在实例对象是空的情况才会去加锁创建对象，性能问题得到了一定程度上的解决，也不会和饿汉一样有内存浪费的问题。

![6121a4caaff896eb82e16dbf494a7a22.png][]

但是，这个写法也存在问题，就是会拿到未初始化完全的对象，我之前的一篇文章中也提到这个方式的问题，具体请看[一次群聊引发的血案][Link 1]。

让我这里复用一下我写过的东西。

从CPU的角度来看，instance = new Instance()可以分为分为几个步骤：

1.  分配对象内存空间
2.  执行构造方法，对象初始化
3.  instance指向分配的内存地址

实际上，**由于指令重排的问题，2、3的步骤可能会发生重排序**，那么问题就发生了。

![ffebddea662503bcc9ccecca900f9463.png][]

instance先被指向内存地址，然后再执行初始化，如果此时另外一个线程来访问getInstance方法，就会拿到instance不是null，最后拿到的将是一个没有被完全初始化的对象！

现在也有很多人说这个问题在高版本的JDK中已经解决了，但是我是没发现有什么直接证据，如果你知道，请你告诉我。

### 静态内部类 ###

这个通过JVM来保证创建单例对象的线程安全和唯一性，是比较好的办法。

`Singleton`类加载的时候，`SingletonHolder`不会加载，只有在调用`getInstance`方法的时候才会执行初始化，这样既起到了懒加载的作用，同时又使用到了JVM类加载机制，保证了单例对象初始化的线程安全。

这种方式也是目前比较推荐的一种方式。

![c0c23a1da290828a905e93f3db1c1b48.png][]

**枚举**

通过枚举来实现单例是Effective Java作者 Josh Bloch 提倡的方式，也是单例模式的最佳实现方式。

![ceb6d1b63f8b0d20a5bb88da6b8d4418.png][]

为了看清楚枚举怎么实现单例模式的，我们来编译一下枚举生成的最终字节码。

执行`javac Singleton.java`生成`class`文件，接着执行`javap -p Singleton.class`，得到如下内容：

![2cdd7205ab5932b2f0957647982993ab.png][]

为了看到更详细的内容，我们执行 `javap -c Singleton`。

![9c603bdca9cf9137bb5ebea97b26ffe8.png][]

通过最终生成的字节码，我们其实发现本质上枚举的初始化通过`static`代码块来进行初始化。

考虑下类加载的几个步骤，**加载->验证->准备->解析->初始化**，最终初始化就是执行`static`代码块，而`static`代码块是绝对线程安全的，只能由JVM来调度，这样保证了线程安全。

枚举的实现方式好处还不止于此，除了一目了然的实现简单之外，还能防止其他几种实现方式避免不了的几个问题。

# 再说几种方式的问题 #

### 反射破坏单例 ###

除了枚举之外，其他的几种方式都可以通过反射的方式达到破坏单例的目的，就随便以一个实现方式来举例，这里最终的输出结果是`false`。

如果拿去尝试反射创建枚举对象的话，则是会报错，可以自己动手尝试一下。

![11776d3dd822b2202e24b7e09f6c0d8d.png][]

为什么会报错，可以直接看一下`newInstance`的源码，有一段特殊的关于枚举类型的判断，下图中我红色标记的部分。

![e2d05a5bbff6d878be32299ca5d9a19e.png][]

### 序列化 ###

除了众所周知的使用反射来破坏单例之外，还有另外一种能破坏单例的方式就是序列化。

对上面的饿汉方法实现序列化，然后得到的结果是`false`，序列化前后对象发生了改变。

![ff64427962411ec5f489e59187208dec.png][]

其实关键的部分在于`ois.readObject`方法，一路跟踪最后找到一段代码如下：

![4be345c11bffea46ef40e01822a42bfb.png][]

所以很明显我们发现了最终实际上这里通过反射创建了一个新的对象，`isInstantiable`实际代表的应该是类或者属性是序列化的，那么久就返回true，我们这里肯定是true，所以最终产生了一个新的对象。

枚举为啥可以防止这个问题？枚举的实现方式不太一样而已，同样跟踪到枚举部分的实现逻辑。

下图中红框标注的部分就是枚举类型去实现反序列化的逻辑，最终只是通过`valueOf`方法查找枚举，不存在新建一个对象的逻辑。

![40a4e1b79bb88a079fc19bccf43ab526.png][]

那么，怎么防止其他方式序列化对单例的破坏？再往下看看源码，红框标注的意思只要有`readResolve`方法就可以解决问题了。

![0b162aadfca123383c0c9f7c5d7b31fe.png][]

实际上，最终解决方案也很简单，单例类加上方法即可。

![13c66d90ef21dbd1d5352d119df3394c.png][]

好了，打完收工。现在是北京时间4月15日凌晨1点整，困了，睡觉。

[bb96b16bb34f3b8e27fa22f15750c6a2.png]: /images/20221022/ab8c20dee7a84108bf87bc2f1229152f.png
[f23b0ec2191547bdc0f5d224b57b8110.png]: /images/20221022/6fff7e7ba6ca4c21a7cb8c84569587e0.png
[6121a4caaff896eb82e16dbf494a7a22.png]: /images/20221022/f23120b993c64883b9a564eec4378daa.png
[Link 1]: https://mp.weixin.qq.com/s?__biz=MzkzNTEwOTAxMA%3D%3D&chksm=c2b24600f5c5cf166c2099a658575ac84c2443e319c5dd7a4c5ea13a67248e2af38009fa57e5&idx=1&lang=zh_CN&mid=2247487229&scene=21&sn=697bf7e5f85eeb39b2bc7b5ece2f5124&token=615512154#wechat_redirect
[ffebddea662503bcc9ccecca900f9463.png]: /images/20221022/1e35bcb93b0e4223b8c26a3fc11cfede.png
[c0c23a1da290828a905e93f3db1c1b48.png]: /images/20221022/1314dd923003449e8498624edd45c5d6.png
[ceb6d1b63f8b0d20a5bb88da6b8d4418.png]: /images/20221022/818e422616a14f1c9980544ddb3b97b0.png
[2cdd7205ab5932b2f0957647982993ab.png]: /images/20221022/8e196f5b07ea4c73933b7b66ed80d2f6.png
[9c603bdca9cf9137bb5ebea97b26ffe8.png]: /images/20221022/dfebd2586d5044caaf794621a82678d2.png
[11776d3dd822b2202e24b7e09f6c0d8d.png]: /images/20221022/9b59d87b7bf64a42b46c5cb050470a68.png
[e2d05a5bbff6d878be32299ca5d9a19e.png]: /images/20221022/92af0bf9a6b845ed95487d45725e9826.png
[ff64427962411ec5f489e59187208dec.png]: /images/20221022/c2f5af6b5d064dcab4cdfcb8bdd6d7bd.png
[4be345c11bffea46ef40e01822a42bfb.png]: /images/20221022/a828e1f54130453fb361dc941a4e1ea2.png
[40a4e1b79bb88a079fc19bccf43ab526.png]: /images/20221022/4f09413ec69c4878a021aefd4f6f610e.png
[0b162aadfca123383c0c9f7c5d7b31fe.png]: /images/20221022/39081898692443a79c317a85d110eddb.png
[13c66d90ef21dbd1d5352d119df3394c.png]: /images/20221022/c6f26fab01504ce3ae168f61ec1c2fd7.png