【缺陷周话】第23期：双重检查锁定

在程序开发中，有时需要推迟一些高开销的对象初始化操作，并且只有在使用这些对象时才进行初始化，此时可以采用双重检查锁定来延迟对象初始化操作。双重检查锁定是设计用来减少并发系统中竞争和同步开销的一种软件设计模式，在普通单例模式的基础上，先判断对象是否已经被初始化，再决定要不要加锁。尽管双重检查锁定解决了普通单例模式的在多线程环境中易出错和线程不安全的问题，但仍然存在一些隐患。本篇文章以 JAVA 语言源代码为例，分析双重检查锁定缺陷产生的原因以及修复方法。详见CWE ID 609: Double-Checked Locking (http://cwe.mitre.org/data/definitions/609.html)。

2、 双重检查锁定的危害

双重检查锁定在单线程环境中并无影响，在多线程环境下，由于线程随时会相互切换执行，在指令重排的情况下，对象未实例化完全，导致程序调用出错。

3、示例代码

示例源于Samate Juliet Test Suite for Java v1.3 (https://samate.nist.gov/SARD/testsuite.php)，源文件名：CWE609_Double_Checked_Locking__Servlet_01.java。

3.1缺陷代码

上述代码行23行-38行，程序先判断 stringBad 是否为 null，如果不是则直接返回该 String 对象，这样避免了进入 synchronized 块所需要花费的资源。当 stringBad 为 null 时，使用 synchronized 关键字在多线程环境中避免多次创建 String 对象。在代码实际运行时，以上代码仍然可能发生错误。

对于第33行，创建 stringBad 对象和赋值操作是分两步执行的。但 JVM 不保证这两个操作的先后顺序。当指令重 排序 后，JVM 会先赋值指向了内存地址，然后再初始化 stringBad 对象。如果此时存在两个线程，两个线程同时进入了第27行。线程1首先进入了 synchronized 块，由于 stringBad 为 null，所以它执行了第33行。当 JVM 对指令进行了重排序，JVM 先分配了实例的空白内存，并赋值给 stringBad，但这时 stringBad 对象还未实例化，然后线程1离开了 synchronized 块。当线程2进入 synchronized 块时，由于 stringBad 此时不是 null ,直接返回了未被实例化的对象（仅有内存地址值，对象实际未初始化）。后续线程2调用程序对 stringBad 对象进行操作时，此时的对象未被初始化，于是错误发生。

使用360代码卫士对上述示例代码进行检测，可以检出“双重检查锁定”缺陷，显示等级为中。在代码行第27行报出缺陷，如图1所示：

图1：“双重检查锁定”的检测示例

3.2 修复代码

在上述修复代码中，在第23行使用 volatile 关键字来对单例变量 stringBad 进行修饰。 volatile 作为指令关键字确保指令不会因编译器的优化而省略，且要求每次直接读值。

由于编译器优化，代码在实际执行的时候可能与我们编写的顺序不同。编译器只保证程序执行结果与源代码相同，却不保证实际指令的顺序与源代码相同，在单线程环境中并不会出错，然而一旦引入多线程环境，这种乱序就可能导致严重问题。 volatile 关键字就可以从语义上解决这个问题，值得关注的是 volatile 的禁止指令重排序优化功能在 Java 1.5 后才得以实现，因此1.5 前的版本仍然是不安全的，即使使用了 volatile 关键字。

使用360代码卫士对修复后的代码进行检测，可以看到已不存在“双重检查锁定”缺陷。如图2：

图2：修复后检测结果

4 、如何避免双重检查锁定

要避免双重检查锁定，需要注意以下几点：

（1）使用 volatile 关键字避免指令重排序，但这个解决方案需要 JDK5 或更高版本，因为从JDK5 开始使用新的 JSR-133 内存模型规范，这个规范增强了 volatile 的语义。

（2）基于类初始化的解决方案。

JVM在类的初始化阶段（即在Class被加载后，且被线程使用之前），会执行类的初始化。在执行类的初始化期间，JVM会去获取一个锁。这个锁可以同步多个线程对同一个类的初始化。