上一章讲解的 Monitor 主要关注的是访问共享变量时，保证临界区代码的原子性。而这一章将深入学习共享变量在多线程间的可见性问题与多条指令执行时的有序性问题。

1. Java 内存模型

JMM 即 Java Memory Model，它定义了主存、工作内存抽象概念，底层对应着 CPU 寄存器、缓存、硬件内存、CPU 指令优化等。

JMM 主要要解决的三方面问题为：

• 原子性 - 保证指令不会受到线程上下文切换的影响
• 可见性 - 保证指令不会受 cpu 缓存的影响
• 有序性 - 保证指令不会受 cpu 指令并行优化的影响

2. 可见性

2.1 一个现象：退不出的循环

先来看一个现象，main 线程对 run 变量的修改对于 t 线程不可见，导致了 t 线程无法停止：

static boolean run = true;

public static void main(String[] args) throws InterruptedException {
    
    Thread t = new Thread(()->{
        while (run) {
            // ....
        }
    });
    t.start();
    
    sleep(1);
    run = false; // 线程t不会如预想的停下来
}

为什么会出现这样的情况呢？下面分析一下：

初始时，t 线程从主内存中读取了 run 的值到工作内存中：

但因为 t 线程需要频繁访问 run 变量，JIT 编译器会将 run 的值缓存至自己工作内存中的高速缓存中，从而减少对主存中 run 的访问，来提高效率。但之后 main 线程修改了主存中 run 的之后，t 线程仍然是从自己的高速缓存中读取 run 变量的值，这样读到的就永远是旧值，从而导致了循环无法退出。这个过程如下图所示：

2.2 解决方法

解决方法：给变量加上 volatile 关键字，它可以用来修饰成员变量和静态成员变量，他可以避免线程从自己的工作缓存中查找变量的值，必须到主存中获取它的值，线程操作 volatile 变量都是直接操作主存。，因此，volatile 关键字保证了在多个线程之间，一个线程对 volatile 变量的修改对另一个线程可见。

所以上面问题的解决方法就是这样定义 run 变量：

volatile static boolean run = true;

另一种解决办法就是把对 run 变量的访问放到 synchronized 块里面，这样也可以保证可见性，但这样就变得有点重量级了：

static boolean run = true;

...

synchronized (obj) {
    if (!run) {
        ...
    }
}

2.3 可见性 VS 原子性

前面例子体现的实际就是可见性，它保证的是在多个线程之间，一个线程对 volatile 变量的修改对另一个线程可见，不能保证原子性，仅用在一个写线程，多个读线程的情况。

如果你真的想保证原子性，那只能老老实实地加锁了。

synchronized 语句块既可以保证代码块的原子性，也同时保证代码块内变量的可见性。但缺点是 synchronized 是属于重量级操作，性能相对更低。

---

如果在前面示例的死循环中加入 System.out.println() 会发现即使不加 volatile 修饰符，线程 t 也能正确看到对 run 变量的修改了，想一想为什么？

因为其内部包含了 synchronized 的使用。

2.4 案例：终止模式之两阶段终止模式

Two Phrase Termination，指的是在一个线程 T1 中如何“优雅”地终止线程 T2？这里的【优雅】指的是给 T2 一个料理后事的机会。

之前讲的方式使用打断标记来实现的，其实可以用一个 volatile 的 flag 来代替这个打断标记，实现思路类似。

2.5 案例：同步模式之 Balking

2.5.1 定义

Balking （犹豫）模式用在一个线程发现另一个线程或本线程已经做了某一件相同的事，那么本线程就无需再做了，直接结束返回。

2.5.2 实现

通过设置一个 volatile 的标记变量，来表示是否已经有其他线程做了某件事。然后每个线程在想做这件事之前，先检查一下这个标记变量：

public class MonitorService {
    
    // 用来表示是否已经有线程已经在执行启动了
    private volatile boolean starting;
    
    public void start() {
        log.info("尝试启动监控线程...");
        synchronized (this) {
            if (starting) {
                return;
            }
            starting = true;
        }
        
        // 真正启动监控线程...
    }
}

2.5.3 应用——单例模式

这种思路经常用来实现单例模式：

public final class Singleton {
    
    private Singleton() { }
    
    private static Singleton INSTANCE = null;
    public static synchronized Singleton getInstance() {
        if (INSTANCE != null) {
            return INSTANCE;
        }
        
        INSTANCE = new Singleton();
        return INSTANCE;
    }
}

对比一下保护性暂停模式：保护性暂停模式用在一个线程等待另一个线程的执行结果，当条件不满足时线程等待。

3. 有序性

3.1 指令重排

3.1.1 什么是指令重排？

JVM 会在不影响正确性的前提下，可以调整语句的执行顺序。思考下面一段代码：

static int i;
static int j;

// 在某个线程内执行如下赋值操作
i = ...; 
j = ...;

可以看到，至于是先执行 i 还是先执行 j ，对最终的结果不会产生影响。所以，上面代码真正执行时，既可以是先执行对 i 的赋值，也可以是先执行对 j 的赋值。

这种特性称之为『指令重排』，多线程下『指令重排』会影响正确性。为什么要有重排指令这项优化呢？从 CPU 执行指令的原理来理解一下吧

3.1.2 指令重排与现代处理器的关系

现代处理器会设计为一个时钟周期完成一条执行时间最长的 CPU 指令。为什么这么做呢？可以想到指令还可以再划分成一个个更小的阶段，例如，每条指令都可以分为：取指令 - 指令译码 - 执行指令 - 内存访问 - 数据写回 这 5 个阶段。

在不改变程序结果的前提下，这些指令的各个阶段可以通过重排序和组合来实现指令级并行，这一技术在 80's 中叶到 90's 中叶占据了计算架构的重要地位。

指令重排的前提是：重排指令不能影响结果。

3.1.3 指令重排序导致的诡异的结果

int num = 0;
boolean ready = false;

// 线程1 执行此方法
public void actor1(I_Result r) {
    if (ready) {
        r.r1 = num + num;
    } else {
        r.r1 = 1;
    }
}

// 线程2 执行此方法
public void actor2(I_Result r) { 
    //这里可能发生指令重排序
    num = 2;
    ready = true; 
}

上面两个方法并行运行，r.r1 的值可能是多少呢？以下是可能的情况：

• 情况 1：线程 1 先执行，这时 ready = false，所以 r.r1 的结果为 1
• 情况 2：线程 2 先执行 num = 2，但还没来得及对 ready 赋值为 true 就运行了线程 1，这时 r.r1 的结果为 1
• 情况 3：线程 2 先执行完，这时线程 1 执行 if 分支，得到结果为 4

但还有一个隐晦的可能情况，那就是因为指令重排，导致先执行了线程 2 的 ready = true 但还没执行 num = 2，而同时执行了线程 1，这样 r.r1 的结果就是 0。

这种比较隐晦的情况可能需要大量的测试才可能出现。这可以借助 Java 的并发压测工具 jcstress 来实现。

3.2 volatile 禁止指令重排

volatile 修饰的变量，可以禁用指令重排。可以禁止 volatile 所修饰的变量在方法中赋值之前的重排序。

这样上面的例子就可以通过给 ready 变量加一个 volatile 来防止因指令重排导致的错误结果：

@JCStressTest
@Outcome(id = {"1", "4"}, expect = Expect.ACCEPTABLE, desc = "ok")
@Outcome(id = "0", expect = Expect.ACCEPTABLE_INTERESTING, desc = "!!!!")
@State
public class ConcurrencyTest {
    
    int num = 0;
    volatile boolean ready = false;
    
    @Actor
    public void actor1(I_Result r) {
        if(ready) {
            r.r1 = num + num;
        } else {
            r.r1 = 1;
        }
    }
    
    @Actor
    public void actor2(I_Result r) {
        num = 2;
        ready = true;
    }
    
}

4. volatile 原理

volatile 的底层实现原理是内存屏障，Memory Barrier（Memory Fence）：

• 对 volatile 变量的写指令后会加入写屏障
• 对 volatile 变量的读指令前会加入读屏障

4.1 如何保证可见性？

写屏障（sfence）保证在该屏障之前的，对共享变量的改动，都同步到主存当中：

public void actor2(I_Result r) {
    num = 2;
    ready = true; // ready 是 volatile 赋值带写屏障
    // 写屏障
}

读屏障（lfence）保证在该屏障之后，对共享变量的读取，加载的是主存中最新数据：

public void actor1(I_Result r) {
    // 读屏障
    // ready 是 volatile 读取值带读屏障
    if(ready) {
        r.r1 = num + num;
    } else {
        r.r1 = 1;
    }
}

4.2 如何保证有序性

写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后：

public void actor2(I_Result r) {
    num = 2;
    ready = true; // ready 是 volatile 赋值带写屏障
    // 写屏障
}

读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前：

public void actor1(I_Result r) {
    // 读屏障
    // ready 是 volatile 读取值带读屏障
    if (ready) {
        r.r1 = num + num;
    } else {
        r.r1 = 1;
    }
}

还是那句话，不能解决指令交错：

• 写屏障仅仅是保证之后的读能够读到最新的结果，但不能保证读跑到它前面去
• 而有序性的保证也只是保证了本线程内相关代码不被重排序

4.3 案例：单例模式中的 double-checked locking 问题

以著名的 double-checked locking 单例模式为例：

public final class Singleton {
    private Singleton() { }
    private static Singleton INSTANCE = null;
    
    public static Singleton getInstance() { 
        if (INSTANCE == null) { // t2
            // 首次访问会同步，而之后的使用没有 synchronized
            synchronized(Singleton.class) {
                if (INSTANCE == null) { // t1
                    INSTANCE = new Singleton(); 
                } 
            }
        }
        return INSTANCE;
    }
}

以上的实现特点是：

• 懒惰实例化
• 首次使用 getInstance() 才使用 synchronized 加锁，后续使用时无需加锁
• 有隐含的，但很关键的一点：第一个 if 使用了 INSTANCE 变量，是在同步块之外，无法保证它的原子有序和可见性。

在多线程环境下，上面的代码就会出现一个很隐藏的问题，我们来看一下 getInstance() 方法的字节码：

其中：

• 17 表示创建对象，将对象引用入栈 // new Singleton
• 20 表示复制一份对象引用 // 引用地址
• 21 表示利用一个对象引用，调用构造方法
• 24 表示利用一个对象引用，赋值给 static INSTANCE

也许 jvm 会优化为：先执行 24，再执行 21。如果两个线程 t1，t2 按如下时间序列执行：

关键在于 0: getstatic 这行代码在 monitor 控制之外，它就像之前举例中不守规则的人，可以越过 monitor 读取 INSTANCE 变量的值，而这时 t1 还未完全将构造方法执行完毕，如果在构造方法中要执行很多初始化操作，那么 t2 拿到的是将是一个未初始化完毕的单例。

简单说就是，线程 t1 可能对 INSTANCE 创建了关联引用，但还没完成这个对象的初始化，而 t2 在 synchronized 外面检查发现 INSTANCE 不为 null 便直接开始用这个未初始化完的对象。

出现这个现象的原因就在于，INSTANCE = new Singleton() 这一行代码不是原子性的，正常需要先构造出对象再关联 INSTANCE 引用，但 JVM 可能对指令重排序导致出现先关联 INSTANCE 到内存的引用，再在这块内存上构造对象。

解决方法：对 INSTANCE 使用 volatile 修饰即可，可以禁用指令重排，但要注意在 JDK 5 以上的版本的 volatile 才会真正有效。

JDK 1.5 及之前的版本中，即使加上 volatile 也不能保证可见性和有序性。

4.4 解决单例模式中 double-checked locking 的问题

下面这个代码是对的，这也是双重检查锁的经典实现代码：

public final class Singleton {
    private Singleton() { }
    private static volatile Singleton INSTANCE = null;
    
    public static Singleton getInstance() {
        // 实例没创建，才会进入内部的 synchronized代码块
        if (INSTANCE == null) { 
            synchronized (Singleton.class) { // t2
                // 也许有其它线程已经创建实例，所以再判断一次
                if (INSTANCE == null) { // t1
                    INSTANCE = new Singleton();
                }
            }
        }
        return INSTANCE;
    }
}

注意要给 INSTANCE 声明时加一个 volatile 关键字。

下面分析一下这样写为什么是正确的。

从字节码的角度上是看不出来 volatile 指令的效果的：

如上面的注释内容所示，读写 volatile 变量时会加入内存屏障（Memory Barrier（Memory Fence）），保证下面两点：

• 可见性
  • 写屏障（sfence）保证在该屏障之前的 t1 对共享变量的改动，都同步到主存当中
  • 而读屏障（lfence）保证在该屏障之后 t2 对共享变量的读取，加载的是主存中最新数据
• 有序性
  • 写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后
  • 读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前

通过这样的保证，可以保证给 INSTANCE 赋值了之后，其引用的对象一定是构造完成的，即调用构造方法的指令（invokespecial）一定是在给 INSTANCE 赋值的指令（putstatic）前面执行，从而保证了 t2 检查 INSTANCE 不为空时一定是可以使用这个单例对象的。指令执行关系如下图：

更底层的实现是读写变量时使用 lock 指令来实现多核 CPU 之间的可见性与有序性。

5. happens-before 规则

happens-before 规定了对共享变量的写操作对其它线程的读操作可见，它是可见性与有序性的一套规则总结，抛开以下 happens-before 规则，JMM 并不能保证一个线程对共享变量的写，对于其它线程对该共享变量的读可见。

情况 1：线程解锁 m 之前对变量的写，对于接下来对 m 加锁的其它线程对该变量的读可见

static int x;
static Object m = new Object();

new Thread(()->{
    synchronized(m) {
        x = 10;  // 写 x
    }
},"t1").start();

new Thread(()->{
    synchronized(m) {
        System.out.println(x);  // 读 x
    }
},"t2").start();

情况 2：线程对 volatile 变量的写，对接下来其它线程对该变量的读可见

volatile static int x;

new Thread(()->{
    x = 10;
},"t1").start();

new Thread(()->{
    System.out.println(x);
},"t2").start();

情况 3：线程 start 前对变量的写，对该线程开始后对该变量的读可见

static int x; 
x = 10;

new Thread(()->{
    System.out.println(x);
},"t2").start();

情况 4：线程结束前对变量的写，对其它线程得知它结束后的读可见（比如其它线程调用 t1.isAlive() 或 t1.join() 等待它结束）

static int x;

Thread t1 = new Thread(()->{
    x = 10;
},"t1");
t1.start();

t1.join();
System.out.println(x);

情况 5：线程 t1 打断 t2（interrupt）前对变量的写，对于其他线程得知 t2 被打断后对变量的读可见（通过 t2.interrupted 或 t2.isInterrupted）

static int x;

public static void main(String[] args) {
    Thread t2 = new Thread(()->{
        while(true) {
            if(Thread.currentThread().isInterrupted()) {
                System.out.println(x);  // 可以读到对 x 的写操作
                break;
            }
        }
    },"t2");
    t2.start();
    
    new Thread(()->{
        sleep(1);
        x = 10;
        t2.interrupt();
    },"t1").start();
    
    while(!t2.isInterrupted()) {
        Thread.yield();
    }
    System.out.println(x);
}

情况 6：对变量默认值（0，false，null）的写，对其它线程对该变量的读可见

比如 boolean a = false 这种默认值的写入。

情况 7：具有传递性，如果 x -> y 并且 y -> z 那么有 x -> z ，配合 volatile 的防指令重排，有下面的例子

volatile static int x;
static int y;

new Thread(()->{ 
    y = 10;
    x = 20;
},"t1").start();

new Thread(()->{
    // x=20 对 t2 可见, 同时 y=10 也对 t2 可见
    System.out.println(x); 
},"t2").start();

变量都是指成员变量或静态成员变量

6. 习题

6.1 balking 模式习题

希望 doInit() 方法仅被调用一次，下面的实现是否有问题，为什么？

public class TestVolatile {
    volatile boolean initialized = false;
    
    void init() {
        if (initialized) { 
            return;
        } 
        doInit();
        initialized = true;
    }
    
    private void doInit() {
    }
}

答：有问题，因为 volatile 只保证了对共享变量的可见性和有序性，但无法保证上面 init() 方法内的原子性。

6.2 实现线程安全的单例模式

单例模式有很多实现方法，饿汉、懒汉、静态内部类、枚举类，试分析每种实现下获取单例对象（即调用getInstance）时的线程安全，并思考注释中的问题。

• 饿汉式：类加载就会导致该单实例对象被创建
• 懒汉式：类加载不会导致该单实例对象被创建，而是首次使用该对象时才会创建

---

实现 1：

// 问题1：为什么加 final
// 问题2：如果实现了序列化接口, 还要做什么来防止反序列化破坏单例
public final class Singleton implements Serializable {
    // 问题3：为什么设置为私有? 是否能防止反射创建新的实例?
    private Singleton() {}
    // 问题4：这样初始化是否能保证单例对象创建时的线程安全?
    private static final Singleton INSTANCE = new Singleton();
    // 问题5：为什么提供静态方法而不是直接将 INSTANCE 设置为 public, 说出你知道的理由
    public static Singleton getInstance() {
        return INSTANCE;
    }
    public Object readResolve() {
        return INSTANCE;
    }
}

• 问题 1：为了防止子类中的实现会破坏它的单例
• 问题 2：由于反序列化会新生成一个对象，从而破坏单例，所以解决方式就是加一个 readResolve()，这样反序列化时发现定义了这个方法会直接调用你写的这个方法，并再次返回 INSTANCE 从而保证单例。
• 问题 3：设置 private 来防止其他人通过构造器生成新的对象。但无法防止有人通过反射来破坏单例。
• 问题 4：没问题。因为静态成员变量的初始化是在类加载时完成的，这个阶段由 JVM 保证了线程安全。
• 问题 5：为了提供更好的封装性和控制。

---

实现 2：

这里用枚举实现了单例

// 问题1：枚举单例是如何限制实例个数的
// 问题2：枚举单例在创建时是否有并发问题
// 问题3：枚举单例能否被反射破坏单例
// 问题4：枚举单例能否被反序列化破坏单例
// 问题5：枚举单例属于懒汉式还是饿汉式
// 问题6：枚举单例如果希望加入一些单例创建时的初始化逻辑该如何做
enum Singleton { 
    INSTANCE; 
}

• 问题 1：只会有一个单实例，它本质上就是枚举类内部的一个静态成员变量
• 问题 2：不会
• 问题 3：不能。用枚举的好处就是可以防止有人用反射来破坏单例
• 问题 4：不会。枚举类都默认实现了 Serializable 接口，但枚举在实现时就考虑了因反序列化导致破坏单例的问题，并对其进行了预防。
• 问题 5：与实现 1 相同，也是饿汉式。
• 问题 6：可以写个构造方法

---

实现 3：

public final class Singleton {
    private Singleton() { }
    private static Singleton INSTANCE = null;
    // 分析这里的线程安全, 并说明有什么缺点
    public static synchronized Singleton getInstance() {
        if( INSTANCE != null ){
            return INSTANCE;
        } 
        INSTANCE = new Singleton();
        return INSTANCE;
    }
}

是线程安全的，但锁的范围有点大，每次调用该方法都要加锁。

---

实现 4：double-checked locking 方法

public final class Singleton {
    private Singleton() { }
    
    // 问题1：解释为什么要加 volatile ?
    private static volatile Singleton INSTANCE = null;
    
    // 问题2：对比实现3, 说出这样做的意义 
    public static Singleton getInstance() {
        if (INSTANCE != null) { 
            return INSTANCE;
        }
        synchronized (Singleton.class) { 
            // 问题3：为什么还要在这里加为空判断, 之前不是判断过了吗
            if (INSTANCE != null) { // t2 
                return INSTANCE;
            }
            INSTANCE = new Singleton(); 
            return INSTANCE;
        } 
    }
}

可以参考前面，这个就很熟悉了。

• 问题 1：防止因指令重排导致的问题（具体会导致的问题可参考前面 4.3 节）
• 问题 2：减小锁的范围
• 问题 3：防止并发的问题，即第一次检查与进入 synchronized 之间的空隙有多个线程。

---

实现 5：推荐的方式，懒汉式，静态内部类实现：

public final class Singleton {
    private Singleton() { }
    // 问题1：属于懒汉式还是饿汉式
    private static class LazyHolder {
        static final Singleton INSTANCE = new Singleton();
    }
    // 问题2：在创建时是否有并发问题
    public static Singleton getInstance() {
        return LazyHolder.INSTANCE;
    }
}

• 问题 1：懒汉式，静态内部类之后在用到的时候才会去加载
• 问题 2：JVM 保证其安全性

7. 小结

本章重点讲解了 JMM 中的：

• 可见性 - 由 JVM 缓存优化引起
• 有序性 - 由 JVM 指令重排序优化引起
• happens-before 规则
• 原理方面：
  • CPU 指令并行
  • volatile 的原理
• 模式方面：
  • 两阶段终止模式的 volatile 改进
  • 同步模式之 balking
  • 单例模式的设计