Abstract
在开发中，如果某个实例的创建需要消耗很多系统资源，那么我们通常会使用惰性加载机制，也就是说只
有当使用到这个实例的时候才会创建这个实例， 这个好处在单例模式中得到了广泛应用。 这个机制在 single-threaded
环境下的实现非常简单， 然而在 multi-threaded 环境下却存在隐患。 本文重点介绍惰性加载机制以及其在多线程环境
下的使用方法。 （作者 numberzero，参考 IBM 文章《Double-checked locking and the Singleton pattern》 ，欢迎转
载与讨论）
1 单例模式的惰性加载
通常当我们设计一个单例类的时候，会在类的内部构造这个类（通过构造函数，或者在定义处直接创建） ，并对外提
供一个 static getInstance 方法提供获取该单例对象的途径。例如：
1public class Singleton
2 {
3 private static Singleton instance = new Singleton();
4 private Singleton(){
5 …
6 }
7 public static Singleton getInstance(){
8 return instance;
9 }
10 }
这样的代码缺点是： 第一次加载类的时候会连带着创建 Singleton 实例， 这样的结果与我们所期望的不同，
因为创建实例的时候可能并不是我们需要这个实例的时候。同时如果这个 Singleton 实例的创建非常消耗系统资源，
而应用始终都没有使用 Singleton 实例，那么创建 Singleton 消耗的系统资源就被白白浪费了。
为了避免这种情况，我们通常使用惰性加载的机制，也就是在使用的时候才去创建。以上代码的惰性加载
代码如下：
11 public class Singleton{
12 private static Singleton instance = null;
13 private Singleton(){
14 …
15 }
16 public static Singleton getInstance(){
17 if (instance == null)
18 instance = new Singleton();
19 return instance;
20 }
21 }
这样，当我们第一次调用 Singleton.getInstance()的时候，这个单例才被创建，而以后再次调用的时候仅仅返回这个单例就可以了。
2 惰性加载在多线程中的问题
先将惰性加载的代码提取出来：
22 public static Singleton getInstance(){
23 if (instance == null)
24 instance = new Singleton();
25 return instance;
26 }
这是如果两个线程 A 和 B 同时执行了该方法，然后以如下方式执行：
1. A 进入 if 判断，此时 foo 为 null，因此进入 if 内
2. B 进入 if 判断，此时 A 还没有创建 foo，因此 foo 也为 null，因此 B 也进入 if 内
3. A 创建了一个 Foo 并返回
4. B 也创建了一个 Foo 并返回
此时问题出现了，我们的单例被创建了两次，而这并不是我们所期望的。
3 各种解决方案及其存在的问题
3.1 使用 Class 锁机制
以上问题最直观的解决办法就是给 getInstance 方法加上一个 synchronize 前缀，这样每次只允许一个线程调用
getInstance 方法：
27 public static synchronized Singleton getInstance(){
28 if (instance == null)
29 instance = new Singleton();
30 return instance;
31 }
这种解决办法的确可以防止错误的出现，但是它却很影响性能：每次调用 getInstance 方法的时候都必须获得
Singleton 的锁，而实际上，当单例实例被创建以后，其后的请求没有必要再使用互斥机制了
3.2 double-checked locking
曾经有人为了解决以上问题，提出了 double-checked locking 的解决方案
32 public static Singleton getInstance(){
33 if (instance == null)
34 synchronized(instance){
35 if(instance == null)
36 instance = new Singleton();
37 }
38 return instance;
39 }
让我们来看一下这个代码是如何工作的：首先当一个线程发出请求后，会先检查 instance 是否为 null， 如
果不是则直接返回其内容，这样避免了进入 synchronized 块所需要花费的资源。其次，即使第2节提到的情况发生
了，两个线程同时进入了第一个 if 判断，那么他们也必须按照顺序执行 synchronized 块中的代码，第一个进入代码
块的线程会创建一个新的 Singleton 实例，而后续的线程则因为无法通过 if 判断，而不会创建多余的实例。
上述描述似乎已经解决了我们面临的所有问题，但实际上，从 JVM 的角度讲，这些代码仍然可能发生错
误。
对于 JVM 而言，它执行的是一个个 Java 指令。在 Java 指令中创建对象和赋值操作是分开进行的，也就
是说 instance = new Singleton();语句是分两步执行的。 但是 JVM 并不保证这两个操作的先后顺序， 也就是说有可能
JVM 会为新的 Singleton 实例分配空间， 然后直接赋值给 instance 成员， 然后再去初始化这个 Singleton 实例。 这样
就使出错成为了可能，我们仍然以 A、B 两个线程为例：
1. A、B 线程同时进入了第一个 if 判断
2. A 首先进入 synchronized 块，由于 instance 为 null，所以它执行 instance = new Singleton();
3. 由于 JVM 内部的优化机制，JVM 先画出了一些分配给 Singleton 实例的空白内存，并赋值给 instance
成员（注意此时 JVM 没有开始初始化这个实例） ，然后 A 离开了 synchronized 块。
4. B 进入 synchronized 块，由于 instance 此时不是 null，因此它马上离开了 synchronized 块并将结果返
回给调用该方法的程序。
5. 此时 B 线程打算使用 Singleton 实例，却发现它没有被初始化，于是错误发生了。
4 通过内部类实现多线程环境中的单例模式
为了实现慢加载，并且不希望每次调用 getInstance 时都必须互斥执行，最好并且最方便的解决办法如下：
40 public class Singleton{
41 private Singleton(){
42 …
43 }
44 private static class SingletonContainer{
45 private static Singleton instance = new Singleton();
46 }
47 public static Singleton getInstance(){
48 return SingletonContainer.instance;
49 }
50 }
JVM 内部的机制能够保证当一个类被加载的时候， 这个类的加载过程是线程互斥的。 这样当我们第一次调用
getInstance 的时候，JVM 能够帮我们保证 instance 只被创建一次，并且会保证把赋值给 instance 的内存初始化完
毕， 这样我们就不用担心3.2中的问题。 此外该方法也只会在第一次调用的时候使用互斥机制， 这样就解决了3.1中的
低效问题。最后 instance 是在第一次加载 SingletonContainer 类时被创建的，而 SingletonContainer 类则在调用
getInstance 方法的时候才会被加载，因此也实现了惰性加载
