什么是双重检查锁？
双重检查锁（Double-Check Locking），顾名思义，通过两次检查，并基于加锁机制，实现某个功能。
要理解什么是双重检查锁，我们从常见的单例模式说起。看第一个例子：
上图中的单例模式一看就知道存在线程问题，如果两个线程：线程A和线程B，同时访问该类，线程A访问到第6行，在还没有实例化完成的时候，线程B访问到第5行，此时也会判断到instance=null，同样会执行实例化的代码，那么线程A和线程B就都会创建一个Singleton实例。
怎么解决上面出现的多线程并发访问导致的问题呢？
加锁！大家都知道，加锁是解决并发访问的方案，于是对代码进行修改，修改后如下：
基于锁的相关特性，可以保证线程A和线程B对getInstance()方法的互斥性和原子性，线程A获取到锁，访问getInstance方法，判断到instance=null，然后创建instance对象实例，完成后释放锁；线程B获取到锁，进入getInstance方法，判断到instance!=null，直接返回instance对象。这样，保证了线程安全性。
但是，加锁是会产生性能开销的，如果getInstance方法被多个线程频繁调用，将会导致程序性能下降。为了解决加锁导致的性能开销，想到了通过延迟加锁，采用块级锁的方法提高性能降低开销，代码示例如下：
此时，线程A和线程B同时访问getInstance方法，线程A和线程B同时在第5行判断到instance=null，然后获取到锁，执行实例化代码后释放锁，线程B也会获取到锁执行实例化代码，所以这个并没有解决线程同步的问题。那么，在线程B获取到锁之后，再判断一次instance对象是否为null呢？
线程A和线程B同时访问到第5行，然后线程A获取到锁，判断到instance=null，执行实例化代码然后释放锁；线程B获取到锁，判断到instance!=null，直接返回instance对象；线程C在进入第5行后判断到instance!=null，直接返回。这样就减少了锁的开销，提升了性能。
此时看上去双重检查锁机制很完美，创建单例实例没有问题。但是，从JAVA内存模型来讲，这其实是存在问题的，问题就在于，线程C在进入第5行后判断到的不为null的instance对象，可能还没有初始化完成！这就要从执行指令的重排序讲起。
什么是重排序机制
为了提高程序执行性能，编译器和处理器会对指令的处理过程重排序。重排序分为3种类型：
1、编译器优化的重排序。在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序；
2、指令级并行的重排序。现代处理器采用了指令级并行技术将多条指令重叠执行，如果不存在数据依赖性，处理器可以改变代码语句对应指令的执行顺序；
3、内存系统的重排序。由于处理器使用缓存和读/写缓冲区，使得加载和存储操作看上去可能是在乱序执行。
从Java源代码到最终实际执行的指令序列，会经过如下步骤：
重排序可能会出现内存可见性问题，JMM通过内存屏障禁止了一些情况下的处理器重排序，保证了内存可见性问题。同时，基于as-if-serial语义，不管怎么重排序，单线程执行结果不能被改变。
对于具有数据依赖性的多个代码指令，JMM会禁止重排序。但是对于不具有数据依赖性的代码指令，JMM允许执行顺序的重排序，只要保证单线程内执行结果一致即可。见下面的代码：
int a = 1;
int b = 2;
int c = a + b;
第3行由于使用了第1行的执行结果和第2行的执行结果，因此与第1行和第2行存在数据依赖性，因此JMM保证第1行和第2行肯定会在第3行之前执行，不允许重排序。但是第1行和第2行不存在数据依赖性，是允许重排序的，他们之间只要保证执行结果的可见性即可。
回到双重检查锁上来
为什么说线程C在第5行判断到的instance!=null，可能是还未被初始化完成的对象实例呢？因为JMM在创建对象时会分为如下三步：
memory = allocate();//1. 分配对象的内存空间
ctorInstance(memory);//2. 初始化对象
instance = memory;//3. 设置instance指向刚分配的内存地址
从上面可以看到，第2行和第3行执行需要依赖于第1行的执行结果，分配内存空间，存在数据依赖性。
但是第2行和第3行却不存在数据依赖性，这里可能会发生重排序！
也就是说第3行可能会优先于第2行执行，先设置instance指向内存地址，此时instance就!=null；然后再初始化对象。如果初始化对象耗时较长，在还没有初始化完成时，线程C访问getInstance方法，在第5行会判断到instance!=null，直接返回未初始化完成的instance实例对象。
怎么来解决这个问题？这又要说到JMM的happens-before规则。
什么是happens-before规则
从JDK5开始，Java使用新的JSR-133内存模型，使用happens-before的概念来阐述操作之间的内存可见性。在JMM中，如果一个操作的结果需要对另一个结果可见，那么这两个操作之间必须存在happens-before关系。这两个操作既可以是一个线程内，也可以是不同线程。
happens-before规则具有如下语义：
1、一个线程中的每个操作，happens-before于该线程中的任意后续操作；
2、对一个锁的解锁，happens-before于随后对这个锁的加锁；
3、对一个 volatile修饰的变量的写，happens-before于任意后续对该变量的读；
4、如果A happens-before B，B happens-before C，那么A happens-before C。
我们看第3点，如果用volatile修饰instance，那么是不是可以保证程序按照我们的想法执行呢？答案是的！
什么是volatile
要讲volatile，我们从一个例子开始讲起。
上面的代码执行后，按照我们的理解应该是线程run方法里面应该最后跳出循环。但是事实上并不是，这是因为基于JMM，每个线程具有自己的工作内存空间，临界区变量flag处于主内存空间中，每个线程从主内存空间中读flag，在工作空间中写flag，写完后再刷入到主内存空间。这是JMM的基于内存模型，也正是因为这个模型，才会导致多线程的一致性问题。因为如果有多个线程同时从主内存中读取临界区变量，然后修改，就会保证数据的不一致性，所以只能通过加锁来保证主内存区的访问的互斥性。
上面的例子，主线程从主内存区读取到flag=false，同时子线程也从主内存区读取到flag=false，开始执行循环操作。即使主线程修改了flag=true，但是却不能改变子线程工作内存区域的flag的值。要解决这个问题，一是通过加锁实现可见性，二是通过volatile。
volatile的语义是：
1、保证线程之间的可见性，基于JMM内存模型，经过volatile修饰的变量，如果一个线程修改了该变量的值，会立刻刷新到主内存区域，此时基于happens-before规则，其他线程要读该变量的值，必须要写完之后。事实上，基于内存模型，主要是因为在修改了该变量的值后，内存模型会通知其他读取了该值得线程，将值设置为无效，要使用该变量的值，必须从主内存区域重新读取。从而保证了可见性。上例中如果用volatile修改flag后，子线程在遍历时就会重新读取flag的值。
2、volatile修饰的变量禁止重排序。
再次回到双重检查锁
基于volatile修饰的变量禁止重排序的特性，以及volatile的happens-before规则，我们可以在上面的单例代码中通过volatile修改，来最终实现线程安全的单例模式。
