Double Check Lock 是多线程环境下为提升延迟初始化效率而被普遍使用的一种方式。咱们经常会使用延迟初始化,以下降服务启动时间。html
/** * code 1.1 */ @NotThreadSafe public class Client { private LazyInitClass instance ; public LazyInitClass getInstance() { if(instance == null) instance = new LazyInitClass("LazyInitClassFieldName") ; return instance ; } }
代码java
上面的代码是典型的延迟初始化的例子。当上面的例子暴露在多线程环境下时,便会出现各类问题。最明显的错误:方法会返回多个 LazyInitClass 对象。git
/** * code 1.2 */ @NotThreadSafe public class Client { private LazyInitClass instance ; public synchronized LazyInitClass getInstance() { if(instance == null) instance = new LazyInitClass("LazyInitClassFieldName") ; return instance ; } }
代码github
上面的代码在方法层面使用了 synchronized 关键字,每次调用 getInstance 方法都进行同步,的确能够有效避免多线程环境下屡次调用 getInstance 获得不一样的 LazyInitClass 对象。但当 instance 初始化完成后,同步便没有了意义。同步则成为影响 getInstance 性能的关键。有没有一种方法,能够在初始化时进行正确的同步,初始化完成后又避免同步呢?因而 DCL 出现了。segmentfault
/** * code 1.3 */ @NotThreadSafe public class Client { private LazyInitClass instance ; public LazyInitClass getInstance() { if(instance == null){ synchronized(this){ if(instance == null){ instance = new LazyInitClass("LazyInitClassFieldName") ; } } } return instance ; } }
代码安全
很不幸,上述代码在编译器优化、多处理器共享内存的状况下,并不能正常工做。多线程
LazyInitClass 代码以下:并发
/** * code 1.4 */ @NotThreadSafe public class LazyInitClass { private String lazyInitClassField ; public LazyInitClass(String lazyInitClassField) { this.lazyInitClassField = lazyInitClassField ; } }
代码性能
LazyInitClass 实例写入 instance field,与 LazyInitClass 对象内部 lazyInitClassField 对象的初始化两步操做将会出现有序性问题。(详细的有序性描述能够阅读上一篇文章:《Java 并发系列(一):多线程三大特性》)优化
具体表现为:某一线程调用 getInstance 方法后,将获得一个非空的 instance 对象,但却只能看到 lazyInitClassField 的默认值,即:lazyInitClassField 为空字符串,而非构造方法中传入的LazyInitClassFieldName。
/** * code 3.1 */ @ThreadSafe class Client { private final ThreadLocal perThreadInstance = new ThreadLocal(); private LazyInitClass instance ; public LazyInitClass getInstance() { if (perThreadInstance.get() == null) createInstance(); return instance; } private void createInstance() { synchronized(this) { if (instance == null) instance = new LazyInitClass("LazyInitClassFieldName"); } perThreadInstance.set(perThreadInstance); } }
从 JDK5 开始,Java Memory Model 升级,volatile 关键字即可以保证可见性与有序性。
要使 DCL 正常工做,多了一种更为方便的解决方案:
/** * code 3.2 */ @ThreadSafe public class Client { private volatile LazyInitClass instance ; public LazyInitClass getInstance() { if(instance == null){ synchronized(this){ if(instance == null){ instance = new LazyInitClass("LazyInitClassFieldName") ; } } } return instance ; } }
因为 JDK1.2 版本,ThreadLocal 很是慢,因此 JDK 1.2 并不推荐使用 ThreadLocal 解决 DCL 问题。因此 JDK1.3 版本之前,DCL 并无解决方案。
/** * code 3.4 */ @ThreadSafe public class ImmutableLazyInitClass { private final String lazyInitClassField ; public ImmutableLazyInitClass(String lazyInitClassField) { this.lazyInitClassField = lazyInitClassField ; } }
若是 LazyInitClass 对象是不可变对象,则不使用 volatile 关键字 DCL 也能正常工做(code 1.3 所示)。这是由 Java 内存模型中,final 域的特殊语义保证的:final 域能确保初始化过程的安全性,从而能够不受限制地访问不可变对象,并在共享这些对象时无须同步。
/** * code 4.1 */ @ThreadSafe public class Client { private static class LazyInitClassHolder { static LazyInitClass singleton = new LazyInitClass("LazyInitClassFieldName"); } public static LazyInitClass getInstance() { return LazyInitClassHolder.singleton ; } }
这种方式被称为延迟初始化占位类模式,由 Java 语义保证:只有调用了 getInstance 方法后,LazyInitClassHolder.singleton 才会被初始化。因此此方式能完美替代 DCL。
DCL 的使用方式已经被普遍废弃。DCL 之因此出现是由于无竞争同步的执行速度很慢,以及 JVM 启动很慢。但这两个问题已经不复存在,于是它并非一种高效的优化措施。延迟初始化占位类模式能带来相同的优点,并更容易理解。