首先是为了查看DCL的单例模式下指令重排相关的问题，找到了这篇关于DCL单例模式的联合声明，相当权威。
Signed by: David Bacon (IBM Research) Joshua Bloch (Javasoft), Jeff Bogda, Cliff Click (Hotspot JVM project), Paul Haahr, Doug Lea, Tom May, Jan-Willem Maessen, Jeremy Manson, John D. Mitchell (jGuru) Kelvin Nilsen, Bill Pugh, Emin Gun Sirer
联合声明文章地址： The “Double-Checked Locking is Broken” Declaration
本文的所有分析都是基于懒汉模式。Double-Checked Locking将在后续中使用缩写DCL来表示。
DCL模被广泛引用，并作为一种在多线程环境中实现惰性初始化的有效方法使用。
不幸的是，在java中实现时，如果没有额外的同步，它不能以平台无关的方式可靠地工作，当在其他语言中实现时，例如C++，它取决于处理器的内存模型、编译器执行的重排序以及编译器与同步库之间的交互。由于在诸如C++这样的语言中没有进行规定，因此很难对它可以正常工作的情况做出具体说明。可以使用显示内存屏障来使其在C++中工作，但这些在java中并不可用。
第一个例子(单线程版本)：
// Single threaded version
class Foo {
private Helper helper = null;
public Helper getHelper() {
if (helper == null)
helper = new Helper();
return helper;
}
// other functions and members...
}
首先这个例子是一个单线程的版本，开发过程中这么写可能就被开除了。因为在多线程环境中使用这个代码，将会导致很多问题。最明显的是，可能会分配两个或者多个Helper对象，当然解决的方法也非常简单，只需要对getHelper()方法进行同步：
// Correct multithreaded version
class Foo {
private Helper helper = null;
public synchronized Helper getHelper() {
if (helper == null)
helper = new Helper();
return helper;
}
// other functions and members...
}
然后就有了这个正确的多线程版本，在getHelper()方法加上了熟悉的synchronized关键字。
但是上面的代码每次获取Helper对象的时候，都会执行同步操作。synchronized是使用monitor来实现的，java中的每个对象都关联了一个monitor，线程可以对其进行加锁和解锁操作，虽然这些不需要我们显示的去执行，但是每次的加锁解锁还是会消耗资源。当helper属性不为null的时候，就不需要进行同步操作，为了优化，就出现了DCL模式:
// Broken multithreaded version
// "Double-Checked Locking" idiom
class Foo {
private Helper helper = null;
public Helper getHelper() {
if (helper == null)
synchronized(this) {
if (helper == null)
helper = new Helper();
}
return helper;
}
// other functions and members...
}
不幸的是，该代码并不能如我们所愿，在编译器优化或内存多处理器的情况下也是没有办法正常工作的。
在DCL模式下，如果不使用volatile关键字，那么helper = new Helper()；这一行代码并不是原子操作，它可以分为以下三个步骤：
1、分配内存空间
2、初始化对象
3、将对象指向刚分配的内存空间
由于编译器的优化(先统称为编译器优化)，第二步和第三步可能会发生重排序，在某些情况下，其他线程可能会看到一个已经分配了内存但尚未初始化的对象。
鉴于上述解释，许多人建议使用以下代码：
// (Still) Broken multithreaded version
// "Double-Checked Locking" idiom
class Foo {
private Helper helper = null;
public Helper getHelper() {
if (helper == null) {
Helper h;
synchronized(this) {
h = helper;
if (h == null)
synchronized (this) {
h = new Helper();
} // release inner synchronization lock
helper = h;
}
}
return helper;
}
// other functions and members...
}
这段代码将Helper对象的构造放在内部同步块中。直观的想法是，在释放同步时应该有一个内存屏障，它应该防止Helper对象的初始化和对helper字段的赋值重新排序。
不幸的是，这种直觉时错的。同步规则并不是这样工作的。monitorexit的规则是，在monitorexit之前必须执行操作，然后才能释放监视器。然而没有规则说在monitorexit之后的操作不能再监视器释放之前完成。编译器将赋值helper=h移动到同步块内是完全合理和合法的。
到目前为止都没有一个好的方案来解决这个DCL单例模式，所以有一个曲线救国的方案就是使用饿汉模式
class HelperSingleton {
static Helper singleton = new Helper();
}
这种模式固然能解决问题，但是并不能适用所有的场景，如果一开始并不知道需不需要这个类，那么这种解决方案并不能让我们更好的编写程序。
所以在java中，又衍生了一种使用ThreadLocal来解决DCL单例模式的broken
class Foo {
/** If perThreadInstance.get() returns a non-null value, this thread
has done synchronization needed to see initialization
of helper */
private final ThreadLocal perThreadInstance = new ThreadLocal();
private Helper helper = null;
public Helper getHelper() {
if (perThreadInstance.get() == null) createHelper();
return helper;
}
private final void createHelper() {
synchronized(this) {
if (helper == null)
helper = new Helper();
}
// Any non-null value would do as the argument here
perThreadInstance.set(perThreadInstance);
}
}
此技术的性能在很大程度上取决于你拥有的JDK实现，在Sun的1.2实现中，ThreadLocal的执行速度非常慢。它们在1.3中明显更快，并且预计在1.4中会更快。
然而在JDK5，又带来了一种完美的解决方案，volatile关键字。
// Works with acquire/release semantics for volatile
// Broken under current semantics for volatile
class Foo {
private volatile Helper helper = null;
public Helper getHelper() {
if (helper == null) {
synchronized(this) {
if (helper == null)
helper = new Helper();
}
}
return helper;
}
}
JDK5和更高的版本扩展了volatile的语义，这样系统将不允许volatile的写入相对于任何先前的读取或写入重新排序，并且volatile的读取不能相对于任何后续的读取或写入重新排序。通过次更改，可以通过将helper字段使用volatile进行修饰，而让DCL能正常的工作。但是这个代码在JDK4或者更早的版本不会起作用。
举个栗子：
上述的代码中，helper字段用volatile关键字进行了修饰，那么执行helper = new Helper();这一行代码的时候
1、分配内存空间(new关键字)
2、初始化Helper对象
3、给对象和内存空间建立联系
这三点就是有序的，不会进行指令的重排序
ok，前菜已经上齐了。如果只是单纯的面试回答问题，这样已经足够了。
关键来了
Double-Checked Locking Immutable Objects
If Helper is an immutable object, such that all of the fields of Helper are final, then double-checked locking will work without having to use volatile fields. The idea is that a reference to an immutable object (such as a String or an Integer) should behave in much the same way as an int or float; reading and writing references to immutable objects are atomic.
是的，如果Helper是一个不可变对象，即Helper的所有字段都是final的，那么双重检查锁定（Double-Checked Locking）将在不使用volatile字段的情况下正常工作。这个想法是，对于不可变对象（如：String或Integer）的引用应该与int和float的行为类似、读取和写入不可变对象的引用是原子的。
小小的脑袋有大大的疑问…
也就是说如果一个类的所有属性都使用final关键字修饰，那么这个类的实例就是不可变的，即其状态不能被修改。在这种情况下，DCL可以省略volatile关键字。
final关键字肯定是不能防止指令重排的，它的作用是确保变量在初始化之后不被修改。然而，final关键字可以帮助我们避免指令重排带来的问题。
所以我写了下面这个例子：
public class Singleton {
private static Singleton instance;
private final int value;
private Singleton(int value) {
this.value = value;
}
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton(42);
}
}
}
return instance;
}
}
我翻阅了很多资料，找到了final的语义，是这么形容的
在Java中，final域的写入和构造函数的结束是有一个“happens-before”关系的。这意味着，当构造函数执行结束时，所有final域都已被正确初始化，并且对其他线程可见。
在我们之前给的Singleton类的例子中，value属性是使用final关键字修饰的。这意味着当Singleton对象被创建时，value属性会被正确初始化为42。由于final域的写入和构造函数的结束有一个happens-before关系，所以当构造函数执行结束时，value属性已经被正确初始化，并且对其他线程可见。
因此，在我们之前给出的Singleton类的例子中，即使发生指令重排，其他线程也不回看到一个未初始化完成的Singleton对象。因为当其他线程看到instance变量不为null时，Singleton对象已经正确初始化，并且它的value属性已经被正确设置为42。