首先是为了查看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。