1.单例模式
对于Java实现单例模式的方法，相信学习过Java的人一般都会张口就来，懒汉式、饿汉式、枚举等等。
使用最多的同时相对较容易记住的就是懒汉式与饿汉式了，相关代码如下：
懒汉式单例模式：
public class Singleton {
private static Singleton instance;
private Singleton() {
}
public static Singleton getInstance() {
if (null == instance) {
instance = new Singleton();
}
return instance;
}
}
饿汉式单例模式：
public class Singleton {
private static Singleton instance = new Singleton();
private Singleton() {
}
public static Singleton getInstance() {
return instance;
}
}
2.性能分析
对于上面的懒汉式与饿汉式单例模式，哪种要好一些呢？
饿汉式属于典型的以空间换时间，当类装载的时候就会创建类的实例，不管你后面用还是不用，这样对于服务器的内存空间来说肯定是有损耗的，因此延迟加载的懒汉式相对来说要好一些，OK，那么问题来了，我们都知道懒汉式单例模式是非线程安全的，怎样修改能够保证其线程安全呢？
3.线程安全的懒汉式
要保证线程安全，那就加锁喽，如下：
public class Singleton {
private static Singleton instance;
private Singleton() {
}
public synchronized static Singleton getInstance() {
if (null == instance) {
instance = new Singleton();
}
return instance;
}
}
线程安全是保证了，但是我们都知道synchronized将导致性能开销，如果getInstance()方法被多个线程频繁的调用，将会导致程序执行性能的下降。在早期的JVM中，synchronized存在着巨大的性能开销，因此，程序员们想出了一种聪明的解决方法，使用双重检查锁定来降低由于加上synchronized所带来的性能开销，这个方法也是目前在网络上查找单例模式相关方法中所提倡的方式，代码如下：
public class Singleton {
private static Singleton instance;
private Singleton() {
}
public static Singleton getInstance() {
if (null == instance) {
synchronized (Singleton.class) {
if (null == instance) {
instance = new Singleton();
}
}
}
return instance;
}
}
双重检查锁定看起来很完美，当检查到instance为null时，加锁，创建对象，如果instance不为null，则不会执行加锁，这样可以大幅的降低synchronized所带来的性能开销，但是这却是一种错误的优化方式。
4.问题的根源
为什么说这是一种错误的优化方式呢？主要问题还是在instance = new Singleton()这行代码，在编译器执行这行代码时，可以分解为3步：
- （1）分配对象的内存空间；
- （2）初始化对象；
- （3）设置instance变量指向所分配的内存地址。
通过JMM对于重排序的约束来看，对于不影响程序执行结果的重排序JMM是允许的，那么上面的3个步骤，如果将（2）和（3）进行重排序（对于一些编译器，这种重排序是真实发生的），在多线程的情况下，会发生什么呢？
假设A线程在执行instance = new Singleton()，由于（2）和（3）进行了重排序，此时（1）（3）执行完毕，这样instance变量所指向的内存空间值是存在的，如果此时B线程调用if (null == instance) ，则会直接返回instance对象，此时B线程将会看到一个还没有被初始化的对象。
5.解决方式
知晓了问题的所在，那么该如何解决呢？思路有两个：
- （1）不允许进行重排序；
- （2）允许重排序，但是不允许其他线程知道这个重排序。
先来看第一种解决方式，禁止重排序首先会想到的当然是volatile，代码如下：
public class Singleton {
private volatile static Singleton instance;
private Singleton() {
}
public static Singleton getInstance() {
if (null == instance) {
synchronized (Singleton.class) {
if (null == instance) {
instance = new Singleton();
}
}
}
return instance;
}
}
由于instance变量被volatile所修饰，此时在执行instance = new Singleton()时，JMM会禁止编译器与处理器对此进行重排序。
再来看第二种解决方式，如何让其他线程不知道这个重排序的存在呢？
使用类初始化解决方案：JVM在类的初始化阶段，会执行类的初始化，在执行类的初始化期间，JVM会去获取一个锁，这个锁可以同步多个线程对同一个类的初始化。
代码：
public class Singleton {
private static class InstanceHolder {
public static Singleton instance = new Singleton();
}
public static Singleton getInstance() {
return InstanceHolder.instance;
}
}
其实这种解决方案就是使用内部类方式实现单例模式的方法。
6.类的初始化
既然提到了使用类的初始化方式，对于类的初始化做一个记录。
初始化一个类，包括执行这个类的静态初始化（静态代码块）和初始化在这个类中声明的静态字段。根据Java语言规范，在首次发生下列任一情况时，一个类或接口T将被立即初始化：
- （1）T是一个类，而且一个T类型的实例被创建；T t = new T()
- （2）T是一个类，且T中声明的一个静态方法被调用；T.staticMethod()
- （3）T中声明的一个静态字段被赋值；T.param = *
- （4）T中声明的一个静态字段被使用，且该字段不是一个常量；上面的解决方案就是使用这个方式，首次执行getInstance() 方法时，InstanceHolder这个内部类将被初始化。
- （5）T是一个顶级类，而且一个断言语句嵌套在T内部被执行。
多线程下类的初始化过程：
假设有A、B、C 3个线程都要对类Class进行初始化，A、B线程同时执行，C线程后于A、B执行，那么执行过程人为拆分如下：
- （1）第一阶段时序
t1：A、B线程同时尝试获取Class对象的初始化锁，这里假设A线程获取到了初始化锁，B线程进入等待获取初始化锁；
t2：A线程发现对象未被初始化（如state=noInitialization），设置状态为初始化中（如state=initializing）；
t3：A释放初始化锁。 - （2）第二阶段时序
t1：A执行类的静态初始化（静态代码块）和初始化在这个类中声明的静态字段，B获取到初始化锁；
t2：B读取到对象状态为初始化中（state=initializing）；
t3：B释放初始化锁；
t4：B在初始化锁的某个空间（假设p）中等待。 - （3）第三阶段时序
t1：类初始化完成，A获取初始化锁；
t2：A设置类的状态为初始化完成（如state=initialized）；
t3：A唤醒在锁空间（p）中等待的线程；
t4：A释放初始化锁；
t5：线程A的初始化过程完成。 - （4）第四阶段时序
t1：线程B获取初始化锁；
t2：B读取到类的状态为初始化完成（state=initialized）；
t3：B释放初始化锁；
t4：线程B的初始化过程完成。 - （5）第五阶段时序
t1：线程C获取初始化锁；
t2：C读取到类的状态为初始化完成（state=initialized）；
t3：C释放初始化锁；
t4：线程C的初始化过程完成。
本文参考：《Java并发编程的艺术》
