设计模式系列：
30分钟学透设计模式1-单例模式的前世今生
30分钟学透设计模式2-随处可见的Builder模式
30分钟学透设计模式3-使用最多的Iterator模式
30分钟学透设计模式4-最简单的面向接口编程-简单工厂模式
30分钟学透设计模式5-从代理模式到AOP

一、概述

单例模式：是一种对象创建模式，用于产生一个对象的实例。可以确保系统中一个类只产生一个实例。

好处：
- 对于频繁使用的对象，可以省略创建对象所花费的时间。
- 由于new操作次数的减少，对系统内存的使用频率会降低，减轻GC压力，缩短GC停顿时间。
- 由于一个类只有一个实例，可以用来保存一些状态值。

因此:
对于系统的关键组件和频繁使用的对象，使用单例模式可以有效改善系统性能。

二、相关概念

• 静态属性：静态字段的值为一个类的所有实例所共享；在概念上，它的值属于类所有，而不是类的每一个实例/对象所有。
  通俗的讲静态属性的值对类的所有对象来看都是相同的。
• 静态方法：静态属性与类相关联，而不是关联到具体的单个对象；同样，静态方法也可以通过作为整体的类来调用。
  多见于一些工具类。
• 静态属性和方法初始化时机：静态属性和静态方法在JVM类加载时完成其初始化过程。

三、实现条件

• 私有构造方法，一个对象只有一个对象实例，因此不能显示的实例化(new 操作)。
• 存在一个静态属性，且这个属性是这个类的一个对象。
• 使用静态方法获取仅有的这个对象。

四、实现方式

#### 1、饿汉模式（类加载时初始化实例）
“`
public class Singleton {
private Singleton() {} // 条件 1

 private static Singleton instance = new Singleton(); // 条件 2

 public static Singleton getInstance() { // 条件 3
     return instance;
 }

}
“`
从上述的代码可以看到，其遵从了单例模式的三个条件：私有的构造方法、静态对象实例以及获取其的静态方法。

饿汉模式的缺点： 先把结论抛出来：饿汉效率差、饿汉效率差、饿汉效率差…
- 由于在JVM类加载时完成对象实例化过程，因此类加载速度要慢；
- 而且不支持延时加载，虽然并没有使用单例类，但它还是被创建出来了。

那我们尝试修改下代码，不让其在JVM类加载时初始化对象，让其支持延时加载。

2、懒汉方式（类加载时不初始化实例，延时加载）

public class Singleton {
    private Singleton() {} // 条件 1

    private static Singleton instance; // 条件 2，默认为null

    public static Singleton getInstance() { // 条件 3
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

为什么称之为懒汉模式呢？
这是因为其静态属性(条件2)初始值为null，只有当第一次构建单例(条件3)时才会构建并返回。
这里需要注意的是静态方法的初始化时机在类加载，但并非是执行一次此方法。

懒汉模式缺点：先把结论抛出来：懒汉不安全，懒汉不安全，懒汉不安全…

设想这样一种情景：在Singleton类刚完成初始化，此时instance=null, 这时有两个线程同时通过getInstance()方法获取对象实例。
当线程1和线程2同时走到上图的位置上，同时判断为instance=null，此时两个线程均执行之后的new操作。
还有一点是，相对于饿汉模式，懒汉获取instance的速度变慢了。（多了一次判断）

没想到不通过JVM类加载了，竟出现的懒汉线程不安全的现象，那我们尝试修改一下代码。

3、增强型懒汉模式

public class Singleton {
    private Singleton() {} // 条件 1

    private static Singleton instance; // 条件 2，默认为null

    public static synchronized Singleton getInstance() { // 条件 3
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

从代码上看，我们仅仅增加了synchronized同步关键字，就保证了其线程安全性。这样就是最佳实现了吧？
未必，由于方法整体被synchronized同步，而且每次调用只能是单个线程操作，其并发度大大降低。

那应该怎么处理呢？回想我们加synchronized同步关键字的目的？
我们是为了在第一次初始化instance时，防止两个线程同时new操作，才增加的这个关键字。那我们可以在第一次new是使用synchronized同步关键字啊。

那我们再次尝试修改一下代码。

4、双重检测机制（double check）

public class Singleton {
    private Singleton() {} // 条件 1

    private static Singleton instance; // 条件 2，默认为null

    public static Singleton getInstance() { // 条件 3
        if (instance == null) {
            synchronized (Singleton.class) {
                instance = new Singleton();
            }
        }
        return instance;
    }
}

我们把synchronized同步关键字加到了判空的后面。
等一下，这似乎并没有什么卵用啊？在new操作之前加锁，仍然不能改变两个线程new两个实例，只不过是将其new操作在时间上进行了分离。

既然两个new操作在时间上分离了，那第二次new操作我再判空一次？

public class Singleton {
    private Singleton() {} // 条件 1

    private static Singleton instance; // 条件 2，默认为null

    public static Singleton getInstance() { // 条件 3
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

这就是大名鼎鼎的double check型单例模式。

看似完美，难道这就是单例的最佳实现？未必。让我们再次看看下面的代码：

假设这样一种场景，线程1和线程2同时进入单例获取实例对象，存在这样一刻，线程1走到红色的箭头处，线程2走到绿色的箭头处。

此时线程1正在对instance进行实例化；而线程2会存在两种结局，其一是线程1还未创建完，进入下一行等待锁；其二是线程1**“貌似”**已经创建完成，线程1返回instance。

看似并没有什么问题，但问题就出现在这个貌似上，其实线程2并不知道线程1是否完成了创建，反正结果就是instance != null，线程2继续执行。

为什么说貌似会有问题呢？因为 instance != null 并不能代表instance完成了创建。

看到这里，知道结论就行，下面的原理部分可以略过。主要是涉及指令排序惹的祸。

---

我是分割线 ↑
指令重排序：编译器或运行时环境为了优化程序性能而采取的对指令进行重新排序执行的一种手段。
问题就出现在下面这行代码上：

instance = new Singleton();

这行并不是atomic操作，它实际被分成几个步骤：
- 1. allocate memory：分配内存
- 2. initialize the object Singleton into the allocated memory：初始化对象
- 3. assign allocated memory to instance ref：设置instance指向刚分配的内存地址，此时instance != null

但这三条指令顺序，有可能会经过JVM和CPU的优化，指令重排成下面的顺序：1→3→2
此时线程1执行了指令1和3，此刻instance != null，那么线程2走到绿色的箭头上，判空不成立，获取到“半成品”的instance。

我是分割线↓

---

那怎么解决这种由于指令重排序导致的问题呢？
我们可以在instance前面加上volatile关键字。

public class Singleton {
    private Singleton() {} // 条件 1

    private static volatile Singleton instance; // 条件 2，默认为null

    public static Singleton getInstance() { // 条件 3
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

这里简单介绍下volatile关键字，可以略过。结论就是：通过volatile关键字防止指令重排序。

What is the Java volatile keyword?
Essentially, volatile is used to indicate that a variable’s value will be modified by different threads.
Declaring a volatile Java variable means:
* The value of this variable will never be cached thread-locally: all reads and writes will go straight to “main memory”;
* Access to the variable acts as though it is enclosed in a synchronized block, synchronized on itself.

volatile关键字不但可以保证线程访问的变量值是主存中的最新值，而且可以防止指令重排。

OK，到这里终于找到了单例模式的最佳实现了。未必。
据说大部分JVM的implementation并不尊重volatile的规则，并且这个类可以通过反射构造多个实例对象。

5、静态内部类方式

回到懒汉加载方式上，我们只是想延迟加载，但是线程不安全带来的问题，除了加锁外还有没有其他方式呢？

还真有，我们下面通过静态内部类的方式来实现单例。

public class Singleton {
    private Singleton() {} // 条件 1

    private static class Holder {
        private static final Singleton instance = new Singleton(); // 条件 2
    }

    public static Singleton getInstance() { // 条件 3
        return Holder.instance;
    }
}

我们这里引用一个关于内部类的结论：
加载一个类时，其内部类不会同时被加载。一个类被加载，当且仅当其某个静态成员（静态域、构造器、静态方法等）被调用时发生。
这就说明了这种静态内部类的方式其实是一种延迟加载的方式。

上面的代码中，由于 instance 在静态内部类中，并没有作为Singleton的成员属性直接实例化，因此类加载时不会实例化Singleton。
第一次调用getInstance()时将加载内部类Holder，在此内部类中定义了一个static类型的instance，此时首先会初始化instance，由JVM来保证其线程安全性，确保该成员变量只能初始化一次。由于getInstance()方法没有任何线程锁定，其性能不会有任何影响。

6、枚举实现单例模式

借用 《Effective Java》一书中的话，

单元素的枚举类型已经成为实现Singleton的最佳方法。

那我们看下，单元素枚举怎么实现单例呢？

public enum Singleton {
    INSTANCE;

    public void donothing() {
        // donothing
    }
}

由于这种方式的单例在面对复杂序列化以及反射攻击时，都能防止多次实例化。被称为单例模式的最佳实现。