Java ~ 双重检查锁（DCL）的原理与失效原因

前言

    为了保证线程的安全性，往往要以牺牲性能为代价。为了兼得二者，前人进行了多番尝试，也确实创造出诸多有效方案，双重检查锁就是其中的一种。

    DCL：Double Check Lock（双重检查锁）。令人哭笑不得的是，其闻名原因不是因为有效性，而是行业标杆级的错误性。双重检查锁同时体现了同步中的独占性与可见性同等的重要性，因此成为多线程学习中必学的经典案例。

一 双重检查锁（DCL）的原理

    我们以DCL的方式来实现单例模式作为学习举例。

@Data
public class Singleton {

    private static Singleton singleton;
    /**
     * 一
     */
    private String one;
    /**
     * 二
     */
    private String two;
    /**
     * 三
     */
    private String three;
    /**
     * 四
     */
    private String four;

    private Singleton() {
        this.one = "三万里河东入海";
        this.two = "五千仞岳上摩天";
        this.three = "遗民泪尽胡尘里";
        this.four = "南望王师又一年";
    }

    /**
     * 获取实例
     *
     * @return 单例类对象
     */
    public static Singleton getInstance() {
        // 一次检查（非同步）。
        if (Objects.isNull(singleton)) {
            synchronized (Singleton.class) {
                // 二次检查（同步）。
                if (Objects.isNull(singleton)) {
                    singleton = new Singleton();
                }
            }
        }
        return singleton;
    }

}

    如果对多线程有一定了解的同学第一次看到上述这段代码一定会觉得很Nice。首先通过一次非同步的检查过滤掉绝大多数的线程，随后在同步块中对少数通过第一次检查的线程进行第二次检查，因为是同步操作，所以最终初始化操作只会进行一次。即满足了线程安全的要求，又达到了高并发的目的，还兼具延迟初始化的特点。

    但实际上，这段完美的代码却深藏陷阱，它可能会引起一系列的异常，而具体会引起哪些异常则与业务相关，而引起这些异常的根本原因在于DCL的失效。

二 双重检查锁（DCL）的失效原因

    如果你能够看懂上述代码的含义，那么你一定很好的理解了同步中独占性的含义。但如果你没有未能发现其中暗藏的错误，那么对可见性的理解可能还差点火候（说的就是我自己）。

    学习并发编程的同学应该都知道，如果在没有同步的情况下读取一个共享对象，我们看到的很有可能是一个失效值。在上述代码的一次检查中就是这种情况，我们可能会看到一个为null的失效值。DCL采用在同步块中再次检查的方案来规避这种风险，但实际情况往往更加复杂，我们可能会看到一个不完整的对象。

    上图显示的是一个完整的Singleton对象，被分配了内存，并完成了初始化。但在极少数的情况下，也可能会出现下述的情况。

    可以看到，上述对象仅仅是被分配了内存，但并未完成初始化，显然这样的对象是不完整的，但也确实是不为null的，那么在一次检查中，就可能会返回一个不完整对象，那么DCL就失效了。

    为什么会出现这样的情况呢？

    答案：对象的初始化并不是一个原子操作。

    我们可以将对象的的初始化粗略的分为两个部分：实例化和初始化。实例化指系统为对象分配内存；初始化指实例化后的初始操作（例如赋初始值等）。既然对象的初始化是一个复合操作，那么就有发生重排序（关于重排序的相关内容请自行查阅，此处暂不赘述）的可能，如果在对象实例化后，初始化前将对象引用赋予共享变量singleton，就会造成这样的情况。

    但如果继续深究，又会发现似乎没有执行上述操作的可能，同步块不是能避免发生重排序吗？对此我要纠正这个错误的观点。

    注：同步块能够保证多个线程有序的（即同步）执行块中的代码，但并不能避免块中的代码发生重排序（最多是避免同步块内的指令重排序到同步块外）。

    阐明了这一点，我们就能够模拟错误发生的场景。

    线程A操作【设置singleton指向内存空间】和【初始化】两者间发生了重排序，导致线程B在进行一次检查时检测到一个不为null却不完整的对象。

三 避免双重检查锁（DCL）失效

    既然我们已经知道DCL失效的原因是重排序，那我们要做的就是避免它。

    volatile变量是Java语言提供的一种稍弱的同步机制。它有两个重要的特点：不会被重排序；不会被缓存到工作线程的本地内存。基于这两个特点，只需为singleton变量添加volatile关键字，就能够避免避免双重检查锁的失效问题。

@Data
public class Singleton {

    private volatile static Singleton singleton;
    /**
     * 一
     */
    private String one;
    /**
     * 二
     */
    private String two;
    /**
     * 三
     */
    private String three;
    /**
     * 四
     */
    private String four;

    private Singleton() {
        this.one = "三万里河东入海";
        this.two = "五千仞岳上摩天";
        this.three = "遗民泪尽胡尘里";
        this.four = "南望王师又一年";
    }

    /**
     * 获取实例
     *
     * @return 单例类对象
     */
    public static Singleton getInstance() {
        // 一次检查（非同步）。
        if (Objects.isNull(singleton)) {
            synchronized (Singleton.class) {
                // 二次检查（同步）。
                if (Objects.isNull(singleton)) {
                    singleton = new Singleton();
                }
            }
        }
        return singleton;
    }

}

四 学习中的误区

    学习中我曾经陷入这样一个误区，认为令DCL失效的原因不是重排序，而是非同步读取导致读取到不完整的对象导致的，无论是否有重排序都会导致该问题的发生。场景如下：

    上述说法看似合理但其实是错误的，因为在线程B进行一次检查的时刻虽然恰好处于实例化后与初始化前（也就是说这是一个不完整的对象），但相应的引用被没有赋予singleton，因此线程B读取到的依然是一个null。