Java中的双重检索与延迟初始化

一.前言

今天看《Java并发编程的艺术》这本书的时候，看到双重检索这一块内容，我才恍然大悟一个问题：咱们平常写DCL单例的时候（双重检索），为啥要给实例加一个volatile修饰呢？还有这么多种单例模式，有的需要加static，有的需要加volatile，把我搞得有一丢丢混，现在搞懂了，也希望借此分享一下。

二.双重检索

首先说下双重检索的由来：Java多线程中，哟时候需要采用延迟初始化来降低初始化类和创建对象的开销，也因此，有时候可能需要推迟一些高开销对象的初始化操作，并且只有在使用这些对象的时候才进行初始化。

2.1 非延迟化初始化

放出非延迟化初始化的代码：

public class SafeLazyInitialization {
    private static Singleton instance;

    public static Singleton getInstance() {
        if (instance == null) { // 1
            instance = new Singleton(); // 2
        }
        return instance;
    }
}

可以看到，这个代码在单线程下没有啥问题，但是在多线程下就有问题了：

1. 假设A线程执行代码1的同时，B线程执行代码2.
2. 此时A线程看到的instance引用的对象还没有完成初始化。

原因：
实际上，在执行instance = new Singleton()的时候，他的目的是创建一个对象，但这一行代码在实际上可以划分为3行伪代码：

memory = allocate(); // 1.分配对象的内存空间
ctorInstance(memory);// 2.初始化对象
instance = memory;// 3.设置instance指向刚分配的内存地址

而在我们的JVM中，在上述代码中的2和3之间可能会存在重排序。 那么2和3之间的重排序发生之后，伪代码变成这样：

memory = allocate(); // 1.分配对象的内存空间
// 分配内存地址的时候，对象还没有经过初始化
instance = memory;// 3.设置instance指向刚分配的内存地址
ctorInstance(memory);// 2.初始化对象

具体的其他解释往后靠靠，再看下上面代码经过双重检索的优化是咋样的。

2.2 双重检查锁定

public class SafeLazyInitialization { // 1
    private static Singleton instance;// 2

    public static Singleton getInstance() {// 3
        if (instance == null) {// 4 第一次检查
            synchronized (SafeLazyInitialization.class) {// 5 加锁
                if (instance == null) {// 6 第二次检查
                    instance = new Singleton();// 7
                }// 8
            }// 9
        }// 10
        return instance;// 11
    }
}

上述代码中，如果第一次检查instance不为null，那么就不需要执行下面的加锁和初始化操作，同时也可以大幅度降低synchronized带来的性能开销。并且：

• 多个线程试图同时创建对象时，会通过加锁来保证只有一个线程能够创建对象。
• 对象创建好后，执行getInstance（）方法不需要获取锁，直接返回已经创建好的对象。

但是问题还是如2.1中伪代码中提到的，当线程执行到代码4的时候，如果读取到instance不为null时，instance引用的对象有可能还没完成初始化。

提到了两次，那看到这里可能回想，没有完成初始化咋了呢？

答：

• 一个对象的生命周期是加载、校验、准备、解析、初始化。
• 一个对象只有被初始化完成后，才能够当成真正的诞生。（就是可以拿来用了）
• 那问题来了，我执行到代码4的时候，这个对象线程已经知道他不是null了，问题是他没有经过初始化，是不能拿来用的。

也就是说，A线程当代码执行到instance = new Singleton()的时候，如果发生了重排序，另一个B线程可能在代码4中判断instance不为null，并且访问instance所引用的一个未初始化的、理论上不能直接拿来用的对象。

即：在多线程环境下，我必须保证初始化这一步骤在内存地址的设置之前。（因为一旦设置了指针的引用，你instance肯定就不是null了）

memory = allocate(); // 1.分配对象的内存空间
ctorInstance(memory);// 2.初始化对象
instance = memory;// 3.设置instance指向刚分配的内存地址

2.3 基于volatile解决双重检索的延迟初始化方案

解决方案很简单，给instance声明为volatile即可。

public class SafeLazyInitialization { // 1
    private volatile static Singleton instance;// 2

    public static Singleton getInstance() {// 3
        if (instance == null) {// 4
            synchronized (SafeLazyInitialization.class) {// 5
                if (instance == null) {// 6
                    instance = new Singleton();// 7
                }// 8
            }// 9
        }// 10
        return instance;// 11
    }
}

加上了volatile即能保证在多线程环境下，上述伪代码的初始化和分配地址的设定（即代码2和3）之间的重排序会被禁止。 从而保证线性安全的延迟初始化。

三 小总结

这里我就大概的说下，为什么加了volatile就能保证线性安全。

1. 首先加了volatile，相当于是加了一道内存屏障。
2. 而这个内存屏障相当于保证了伪代码中2和3之间的happen-before原则。
3. 即A happen-before B，那么A的执行结果将对B可见，且第一个操作的执行顺序排在第二个之前。
4. 在本案例当中，保证了初始化的发生在（设置instance指向刚分配的内存地址）这个动作之前。

备注：

两个操作之间存在happen-before关系，并不意味着Java平台层面的实现必须按照happen-before关系指定的顺序来执行。
因为：
如果重排序后，与按照happen-before关系来执行的结果一致，那么这种重排序并不非法。
举个例子：
上述伪代码正常的执行顺序是123，咱们万一哪天在代码层面写了了个顺序是132，然后经过JVM的重排序，变成了123，那么这个结果是可接受的，这样的重排序是允许的。（我是这么理解的）