synchronized, volatile 在 DCL 的作用

背景

最近在看设计模式，在单例模式的 Double Check Lock（DCL）中，存在两个关键字：volatile & synchronized。

之前都知道 DCL 怎么写，直接套娃。但是这两关键字在单例里面的作用还没深究过，于是就自言自语一篇文章。

单例模式代码

public class Single {

    private static volatile Single INSTANCE;

    private Single(){}

    public static Single getInstance(){
        //first check object
        if(INSTANCE == null){
            //locks in the class dimension
            synchronized (Single.class){
                //second check object
                if(INSTANCE == null){
                    INSTANCE = new Single();
                }
            }
        }
        return INSTANCE;
    }
}

synchronized & volatile 作用

synchronized 作用

synchronized 是 java 的重量级锁，可作用于方法维度、代码块维度。具体到底层字节码就是 monitor enter & monitor exit。

volatile 作用

volatile 有两个作用

1. 保证可见性。

修饰的变量从主内存 copy 到工作内存，修改后写回到主内存。

作用原理就是读写前 JVM 加一个内存屏障，通过 happen before 原则确保修改可见于读取。

主内存：类比成 JVM 堆

工作内存：类比成 JVM 虚拟机栈

2. 禁止指令重排序。

对象初始化步骤

1. 分配内存空间
2. 实例变量初始化
3. 执行初始化代码块
4. 调用构造函数
5. 静态变量初始化
6. 返回对象引用

刨除非必要步骤，上述 6 步剩下 3 步

1. 分配内存空间
2. 调用构造函数
3. 返回对象引用

synchronized & volatile 在 DCL 缺失的问题

有 synchronized 没有 volatile

由于指令重排序的优化手段，上述创建对象的 1 -> 2 -> 3, 可能顺序变成了 1 -> 3 -> 2。

没有禁止重排序，顺序变了，中间的第三步返回是个空对象，并发情况下就 G 了，另一线程拿的是空对象。

有 volatile 没有 synchronized

并发情况下， A B 两个线程都通过了等于 null 的校验，开始执行创建对象的操作。

上述创建对象说的 1 -> 2 -> 3， A B 两个线程都有可能走完 1 & 2，最后单例对象会是执行慢的线程返回引用的那个。构造函数会执行两遍，违反了单例模式的初衷。

总结

synchronized & volatile 的作用就很明显。

synchronized 保障构造函数只执行一遍，对象也只有一个。

volatile 保障极端情况下不会返回空对象。

题外话

1. 为什么 synchronized 修饰的是代码块，不是静态方法 getInstance ?

为了提升获取单例对象的运行效率。

synchronized 修饰代码块，只会影响进入代码块瞬间的其他线程。

synchronized 修饰方法，会影响调用方法的所有线程。

2. 为什么进入 synchronized 修饰代码块后，还要判断一下单例对象是否等于 null ？

防止重复创建对象。

假设 A B 两个线程

1. A 线程进入同步块，还在上述说的对象初始化三步里面，B 线程进来了，在 synchronized 代码块外自旋。
2. A 线程执行完了，B 线程进代码块了，这时若不判断是否为 null，就会重复创建对象。

本文首发于cartoon的博客

转载请注明出处:https://cartoonyu.github.io