设计模式（01） 单例模式（创建类模式）（下，懒汉模式和双重检查锁）

From Now On，Let us begin Design Patterns。

懒汉模式和双重检查锁

这篇文章我们接着上一篇文章，继续设计模式里面的单例模式：这一篇我们要写的是懒汉模式和双重检查加锁的实例，我用我个人的编程经验跟大家讲述这个很有趣的故事，而且您听完会觉得很简单。

说出我的故事：懒汉模式

刚刚工作的时候，我老大分配给我一个任务：写一个跟fastdfs（一个开源的轻量级分布式文件系统，它对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。特别适合以文件为载体的在线服务，如相册网站、视频网站等等。）的底层系统，我们会用到公司的自己封装的一些jar包。

项目过程中，我需要一个分发请求的类，这个类用于分发所有的存储请求，同时我想实现的是，这个类只能一个，否则无法轮换分发了，所以我的单例是这么实现的：

不完整的懒汉模式：

我要一个单例，所以我就直接写了：如下：

是不是很简单，当时我就是这么写的，哈哈。后来我一看，不对呀！！！！我的构造函数的访问权限是public的，要是我不小心new多了一个或者别人new了呢？？？？所以，我规定只能用private作为构造函数，于是乎，就有了下面的版本：

终于大公告成了吧！！我很有成就感呀，当时我还没看过设计模式，仿佛这就是自己发明得的，老高兴了。
后来我测试项目（公司内部使用），我发现居然没有办法获得单例，这可把我急坏了，一看，妈的原来少了同步关键字：synchronized，于是乎：

完整的懒汉模式：

事情过了一个星期，我老大看我的代码，看到我使用这个单例模式的时候，先是对我肯定了一次，然后提了两点中肯的意见，第一：使用了这种模式的地方命名要规范，方便他人阅读；第二：这个同步方法影响的区域太大，如果多个对象想获取这个对象的时候会柱塞在这排队，建议缩小同步区域。

于是，才有了下文

不完整的双重检查锁：

老大要我将同步块的范围缩小，好说好说，那我就将同步块的大小缩小一下吧：于是，我站在单线程的角度出发，就有了下面的代码：

后来用的时候发现有时候行有时候不行，虽然代码的思路没错，但是这样的实现肯定是有问题的，于是乎我分析了一下，问题如下:
当 instance 为 null 时，两个线程可以并发地进入 if 语句内部。然后，一个线程进入 synchronized 块来初始化 singleton ，而另一个线程则被阻断。当第一个线程退出 synchronized 块时，等待着的线程进入并创建另一个 Singleton 对象。注意：当第二个线程进入 synchronized 块时，它并没有检查 instance 是否非 null。
为处理上面的问题，我们需要对 singleton 进行第二次检查。这就是“双重检查锁定”名称的由来。

所以我的代码就变成了下面的模样：

双重检查锁定背后的理论是：在 //2 处的第二次检查使（如上上例子 中那样）创建两个不同的 Singleton 对象成为不可能。假设有下列事件序列：

1. 线程 1 进入 getInstance() 方法。

2. 由于 singleton为 null，线程 1 在 //1 处进入 synchronized 块。

3. 线程 1 被线程 2 预占。

4. 线程 2 进入 getInstance() 方法。

5. 由于 singleton仍旧为 null，线程 2 试图获取 //1 处的锁。然而，由于线程 1 持有该锁，线程 2 在 //1 处阻塞。

6. 线程 2 被线程 1 预占。

7. 线程 1 执行，由于在 //2 处实例仍旧为 null，线程 1 还创建一个 Singleton 对象并将其引用赋值给 singleton。

8. 线程 1 退出 synchronized 块并从 getInstance() 方法返回实例。

9. 线程 1 被线程 2 预占。

10. 线程 2 获取 //1 处的锁并检查 instance 是否为 null。

11. 由于 singleton是非 null 的，并没有创建第二个 Singleton 对象，由线程 1 创建的对象被返回。

这么一分析，我就很满意啦，这个就能实现单例了吧，当时我是深信不疑的，直到后来。。。。。。

完整的双重检查锁：

后来呀后来，我发现这个单例也是时候时坏的，够呛，我这次努力查资料，算是彻底弄明白了，资料是这么说的：
双重检查锁定背后的理论是完美的。不幸地是，现实完全不同。双重检查锁定的问题是：并不能保证它会在单处理器或多处理器计算机上顺利运行。
双重检查锁定失败的问题并不归咎于 JVM 中的实现 bug，而是归咎于 Java 平台内存模型。内存模型允许所谓的“无序写入”，这也是这些习语失败的一个主要原因。

无序写入带来的问题：

为解释该问题，需要重新考察上例子中的 //3 行。此行代码创建了一个 Singleton 对象并初始化变量 singleton 来引用此对象。这行代码的问题是：在 Singleton 构造函数体执行之前，变量 instance 可能成为非 null 的。

什么？这一说法可能让您始料未及，但事实确实如此。在解释这个现象如何发生前，请先暂时接受这一事实，我们先来考察一下双重检查锁定是如何被破坏的。假设上例 中代码执行以下事件序列：

1.线程 1 进入 getInstance() 方法。

2.由于 singleton 为 null，线程 1 在 //1 处进入 synchronized 块。

3.线程 1 前进到 //3 处，但在构造函数执行之前，使实例成为非 null。

4.线程 1 被线程 2 预占。

5.线程 2 检查实例是否为 null。因为实例不为 null，线程 2 将 singleton引用返回给一个构造完整但部分初始化了的 Singleton对象。

6.线程 2 被线程 1 预占。

7.线程 1 通过运行 Singleton 对象的构造函数并将引用返回给它，来完成对该对象的初始化。

此事件序列发生在线程 2 返回一个尚未执行构造函数的对象的时候。
为展示此事件的发生情况，假设为代码行 instance =new Singleton(); 执行了下列伪代码： instance =new Singleton();

mem = allocate();             //Allocate memory for Singleton object.
instance = mem;               //Note that instance is now non-null, but
                              //has not been initialized.
ctorSingleton(instance);      //Invoke constructor for Singleton passing
                              //instance.

具体的内容大家可以参考：http://blog.youkuaiyun.com/chenchaofuck1/article/details/51702129

为了解决这个无序写入的问题：我们可以用volatile保证写入顺序的一致性：

完整的双重检查锁代码如下：

到这里，总算完成了懒汉模式和双重检查锁的代码啦。其实综合来看：我们的选择顺序可以是：静态内部类 > 饿汉模式 > 双重检查锁 > 懒汉模式