概念
单例模式是一种常用的软件设计模式。在应用这个模式时，单例对象的类必须保证只有一个实例存在。本文就从单例模式的两种构建方式来了解一下单例。以下会给出多种单例的实现，有正确的、也有存在缺陷的。最后会总结各个方式优缺点。
分类
- 饿汉式单例模式：指全局的单例实例在类加载时就主动创建实例。
- 懒汉式单例模式：指全局的单例实例在第一次被使用时才创建实例，不使用时不创建实例。
实现方式
1。饿汉式：（记为 实现-1）
形象的描述就是“直接”，想象一下一名饿汉在吃东西时的样子。食物到面前就开吃，简单粗暴。而代码中的体现就是一被加载就构建。实现起来也是简单粗暴，没有缺陷，唯一的不足就是耗费资源。因为就算这个单例没被使用到，它也会被实例化，占用内存。
示例代码
public class Singleton {
private static Singleton instance= new Singleton();
private Singleton() {
}
public static Singleton getInstance() {
return instance;
}
}
饿汉式的单例模式上面代码就已经实现了，我们平时使用时是这样的：Singleton.getInstance();
当方法被调用时Singleton第一次被使用，此时类被加载。类加载过程中静态变量被初始化，instance 实例也就是在这时候被构建。
2.懒汉式
懒汉式通俗的解释起来就是，懒人干的事情，懒人做事就是需要做的时候才去做。在代码上的体现就是延时加载。
下面来一步步从 缺陷到 完善 实现懒汉式单例模式：
-
实现 - 2 （存在缺陷的实现）
我们经常会写以下代码来实现单例模式，但是这种实现方式存在弊端：线程不安全。
示例代码
public class Singleton {
private final static Singleton instance;
public static Singleton getInstance() {
if (instance== null) {
instance= new Singleton();
}
return instance;
}
}
我们来分析缺陷所在：
假设线程1、2同时调用getInstance()，线程1准备执行 instance= new Singleton(); 时被线程2预占。因为此时insteance 还未被示例话，所以线程2可以执行完整个getInstance()方法，返回了Singleton对象引用。此时线程1在它停止的地方启动，执行接下来的代码，由于已经进行过了非空判断，所以接下来就错误的再次实例化了一个Singleton对象。此时就示例化了两个Singleton对象。反之，如果能保证是单线程使用此单例对象，这种实现方式是没有问题的。
-
实现 - 3 （对实现 - 2进行改进）
实现2中既然存在线程不安全的问题，那么很容易就想到一个处理方法，那就是加锁。
示例代码
public class Singleton {
private final static Singleton instance;
public static synchronized Singleton getInstance() {
if (instance== null) {
instance= new Singleton();
}
return instance;
}
}
这种实现与 实现2 相比较，差别就在于一个同步锁。加了锁的getInstance() 可以保证线程安全，并且也实现了单例。
这一种正确的单例实现方式，但是由于对 getInstance()做了同步处理，synchronized将导致性能开销。
分析这种实现发现其实只有在第一次调用方法时才需要同步。（此处自行理解下）
由于只有第一次调用执行了 instance= new Singleton()，而只有此行代码需要同步，因此就无需对后续调用使用同步。除了第一次调用外其他的调用都只需要判断 instance是否为 null，并将其返回。多线程能够安全并发地执行除第一次调用外的所有调用。
由于该方法是synchronized 的，需要为该方法的每一次调用付出同步的代价，即使只有第一次调用需要同步。所以如果getInstance()被多个线程频繁的调用，将会导致程序执行性能的下降。反之，如果getInstance()不会被多个线程频繁的调用，那么这个延迟初始化方案将能提供令人满意的性能。
既然有性能上的不足，那么我们伟大的程序猿自然会想出优化性能的方法。所以就有了接下的的这种实现 双重检查锁定
-
实现 - 4 （对实现 - 3进行性能优化后的实现 - 双重检查锁定 double-checked locking）
先声明，双重检查锁定这种实现方式是一种存在漏洞的单例实现
示例代码
public class Singleton {
private final static Singleton instance;
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance== null) {
instance= new Singleton(); // 问题出现位置
}
}
}
return instance;
}
}
上面的代码就是 双重检查锁定的实现方式。
分析 实现 - 4 的代码：
如果第一次检查instance不为null，那么就不需要执行下面的加锁和初始化操作。因此可以大幅降低synchronized带来的性能开销。上面代码表面上看起来，似乎两全其美：
1. 在多个线程情况下同一时间调用getInstance()时，会通过加锁来保证只有一个线程能创建对象。
2.在对象创建好之后，执行getInstance()将不需要每次都获取锁，直接返回已创建好的对象，优化了实现-3 中多次获取锁导致的性能消耗。
双重检查锁定看起来似乎很完美，但这是一个错误的优化！在线程执行到第4行代码读取到instance不为null时，instance引用的对象有可能还没有完成初始化。
该问题的具体分析请看这里 ：http://www.infoq.com/cn/articles/double-checked-locking-with-delay-initialization
我在这里做简单的分析并给出解决方式
前面的双重检查锁定示例代码的第7行instance = new Singleton()创建一个对象。这一行代码可以分解为如下的三行伪代码：
memory = allocate(); //1：分配对象的内存空间
ctorInstance(memory); //2：初始化对象
instance = memory; //3：设置instance指向刚分配的内存地址
上面三行伪代码中的2和3之间，可能会被重排序（在一些JIT编译器上，这种重排序是真实发生的，详情见参考文献1的“Out-of-order writes”部分）。2和3之间重排序之后的执行时序如下：
memory = allocate(); //1：分配对象的内存空间
instance = memory; //3：设置instance指向刚分配的内存地址
//注意，此时对象还没有被初始化！
ctorInstance(memory); //2：初始化对象
根据《The Java Language Specification, Java SE 7 Edition》（后文简称为java语言规范），所有线程在执行java程序时必须要遵守intra-thread semantics。intra-thread semantics保证重排序不会改变单线程内的程序执行结果。换句话来说，intra-thread semantics允许那些在单线程内，不会改变单线程程序执行结果的重排序。上面三行伪代码的2和3之间虽然被重排序了，但这个重排序并不会违反intra-thread semantics。这个重排序在没有改变单线程程序的执行结果的前提下，可以提高程序的执行性能。
为了更好的理解intra-thread semantics，请看下面的示意图（假设一个线程A在构造对象后，立即访问这个对象）：
如上图所示，只要保证2排在4的前面，即使2和3之间重排序了，也不会违反intra-thread semantics。
下面，再让我们看看多线程并发执行的时候的情况。请看下面的示意图：
上图标识什么意思呢？
由于单线程内要遵守intra-thread semantics，从而能保证A线程的程序执行结果不会被改变。但是当线程A和B按上图的时序执行时，B线程将看到一个还没有被初始化的对象。
这么说有点抽象，我们回到代码分析
示例代码第七行 instance= new Singleton() ，此处若是发生重排序，对象还未被初始化完成。此时另一个并发的线程B就有可能在 第4行判断 instance 不为 null 。那么线程B就将访问未完成初始化的对象。这就是错误所在。
在知晓了问题发生的根源之后，我们可以想出两个办法来实现线程安全的延迟初始化：
1. 不允许2和3重排序；
2. 允许2和3重排序，但不允许其他线程“看到”这个重排序。
既然想到了方法，那么就用代码来实现。
-
解决方案1：实现 - 5 （基于volatile的双重检查锁定）
示例代码
public class Instance {
private volatile static Instance instance;
private Instance (){ }
public static Instance getInstance() {
if (instance== null) {
synchronized (SafeDoubleCheckedLocking.class) {
if (instance== null)
instance= new Instance();//instance 为volatile，现在没问题了
}
}
return instance;
}
}
注意，这个解决方案需要JDK5或更高版本（因为从JDK5开始使用新的JSR-133内存模型规范，这个规范增强了volatile的语义）。当声明对象的引用为volatile后，“问题的根源”的三行伪代码中的2和3之间的重排序，在多线程环境中将会被禁止。禁止后，线程B在进行第一次 instance == null 判断时就不会为true， 将按如下的时序执行：
这个方案本质上是通过禁止上图中的2和3之间的重排序，来保证线程安全的延迟初始化。
解决方案2：实现 - 6（基于类初始化的解决方案 - Initialization On Demand Holder idiom）
示例代码
public class Singleton {
private Singleton() {
}
private static class LazyHolder {
static final Singleton INSTANCE = new Singleton();
}
public static Singleton getInstance() {
return LazyHolder.INSTANCE; // 这里将导致Singleton类被初始化
}
}
JVM在类的初始化阶段（即在Class被加载后，且被线程使用之前），会执行类的初始化。在执行类的初始化期间，JVM会去获取一个锁。这个锁可以同步多个线程对同一个类的初始化。相比其他实现方案（如double-checked locking等），该技术方案的实现代码较为简洁，并且在所有版本的编译器中都是可行的。
补充内容
关于实现 - 6中，static final Instance instance 域的访问权限为什么是包级私有可以读:Initialization On Demand Holder idiom的实现探讨
各种实现方式的优缺点：
-
饿汉式（实现 - 1） 单例实例在类装载时就构建，急切初始化。
- 优点：
- 线程安全
- 在类加载的同时已经创建好一个静态对象，调用时反应速度快。
- 缺点
- 资源效率不高，getInstance()可能永远不会执行到，但执行该类的其他静态方法或者加载了该类（class.forName)，那么这个实例仍然初始化。
- 优点：
-
懒汉式 （实现 2 - 6）单例实例在第一次被使用时构建（调用 getInsteance()），延迟初始化。
- 实现 - 2（缺陷实现）：这种实现方式存在线程不安全的缺陷，不推荐使用。但若能保证处于单线程中，可以使用这种实现方式。
- 实现 - 3（耗资源实现）：这种实现方式对实现-2中线程不安全的缺陷进行了处理。
- 优点：资源利用率高，不执行getInstance()就不会被实例，可以执行该类的其他静态方法。
- 缺点：第一次加载时不够快，多线程使用不必要的同步开销大
- 实现 - 4（问题实现）：双重检查锁定，这是对实现 - 3的一种优化实现，但是存在重排序导致获取到未初始化的单例对象的问题
- 实现 - 5：双重检查锁定+volatile
- 优点：资源利用率高，不执行getInstance()就不会被实例，可以执行该类的其他静态方法。
- 缺点：第一次加载时反应不快。实现起来代码较为复杂。
- 注意点：jdk1.5版本后volatile关键字才能正确的工作。Android平台不同当心这个问题，一般Android都是jdk1.6以上。
- 实现 - 6：静态内部类
- 优点：资源利用率高，不执行getInstance()就不会被实例，可以执行该类的其他静态方法。实现代码较为简洁
- 缺点：第一次加载时反应不快。
总结：
- 延迟初始化降低了初始化类或创建实例的开销，但增加了访问被延迟初始化的字段的开销(锁)。在大多数时候，正常的初始化要优于延迟初始化。
- 如果确实需要对实例字段使用线程安全的延迟初始化，请使用上面介绍的基于volatile的延迟初始化的方案（实现 - 5）；
- 如果确实需要对静态字段使用线程安全的延迟初始化，请使用上面介绍的基于类初始化的方案。（实现 - 6）
- 一般采用饿汉式（实现 - 1），若对资源十分在意建议采用静态内部类（实现 - 6）。
