03. 理解 Java 内存模型（JMM）及 volatile 关键字

1. Java 内存模型（JMM）

Java 内存模型（即 Java Memory Model，简称 JMM）本身是一种抽象的概念，本身并不存在，它描述的是一组规范，这组规范定义了程序中各个变量的访问方式。

• 由于 JVM 运行程序的实体是线程，而每个线程创建时 JVM 都会为其创建一个工作内存，用于存储线程私有的数据。
• 而 Java 内存模型规定所有变量都存储在主内存，主内存是共享内存区域，所有线程都可以访问。
• 但是线程对变量的操作（读取、赋值等）必须在工作内存中进行，首先要将变量从主内存拷贝到自己的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存，不能直接操作主内存中的变量，工作内存中存储着主内存中变量的副本。
• 工作内存是每个线程的私有数据区域，因此不同的线程之间无法访问对方的工作内存，线程间的通信必须通过主内存来完成。

线程、主内存、工作内存之间的交互关系图如下：

2. 内存模型三大特性

定义 Java 内存模型规范的目的就是，解决由于多线程通过共享内存进行通信时存在的原子性、可见性以及有序性问题。

2.1 原子性

原子性是指一个操作是不可中断的（不可分的）。即使是在多线程环境下，一个操作一旦开始就不会被其它线程影响。

比如，对于一个 32 位的虚拟机（每次原子读写是 32 位的），我们用这个虚拟机去读写一个 long 类型的数据（long 类型数据是 64 位的）。如果线程 A 将低 32 位的数值写入之后突然被中断，而此时线程 B 又去读取该数据，那显然读到的是一个错误的数据。

2.2 可见性

可见性是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其它线程能够立即看到修改后的值。

在串行程序中，可见性是不存在的，因为串行程序的顺序执行，我们在任何一个操作中修改了某个变量的值，后续的操作中都能读取到这个变量值，并且是修改过的新值。而在多线程环境下，线程对共享变量的操作都是先拷贝到各自的工作内存，进行操作后再写回到主内存中。

比如，主内存中有一个共享变量 i = 0，线程 A 和线程 B 都要进行 i++ 操作。线程 A 先将 i 拷贝到自己的工作内存中，执行 i++ 后 i = 1，但还没有把 i 的值写回到主内存中；此时，由于线程 A 还没有将 i = 1 写回主内存，所以线程 B 在执行 i++ 操作前从主内存读到的 i 的值还是 0，也就是说，线程 A 对共享变量 i 的操作对线程 B 来说是不可见的。这种工作内存与主内存的同步延迟现象就是可见性问题。

2.3 有序性

有序性是指对于单线程的执行代码，代码的执行是按照顺序依次执行的。但对于多线程环境，由于程序编译成机器码指令后可能出现指令重排现象（随后介绍），重排后的指令与原指令的顺序未必一致，就可能出现乱序现象。

要明白的是，在 Java 程序中，在本线程内，所有的操作都视为有序行为；在多线程环境下，在一个线程中观察另一个线程，所有的操作都是无序的。前半句是指单线程内保证串行语义执行的一致性，后半句指的是指令重排现象和工作内存与主内存的同步延迟现象。

3. 理解 “指令重排”

3.1 什么是指令重排

计算机在执行程序时，如果只能顺序执行，前一段程序执行完才能开始下一段程序的执行，这样显然效率不高。为了提高性能，编译器和处理器常常会对指令进行重排序，使得有些指令可以并行的执行。一般分以下 3 种：

• 编译器优化的重排序： 编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。
• 指令并行的重排序： 现代处理器采用了指令级并行技术来将多条指令并行地执行。如果不存在数据依赖性，处理器可以改变语句对应的机器指令的执行顺序。
• 内存系统的重排序： 由于处理器使用缓存和读写缓冲区，使得加载（load）和存储（store）操作看上去可能是在乱序执行。

其中，编译器优化的重排序属于编译器重排序，指令并行的重排序和内存系统的重排序属于处理器重排序。从 Java 源代码到最终实际执行的指令序列，会分别经历以下 3 种重排序：

3.1.1 as-if-serial 语义

as-if-serial 的意思是不管指令怎么重排序，在单线程下执行的结果不能被改变。不管是编译器级别还是处理器级别的重排序都必须遵守 as-if-serial 语义。

为了遵守 as-if-serial 语义，编译器和处理器不会对存在数据依赖关系的操作做重排序。但是 as-if-serial 规则允许对有控制依赖关系的指令做重排序，因为在单线程程序中，对存在控制依赖的操作重排序，不会改变执行结果，但是多线程下却有可能会改变结果。

• 数据依赖：

    int a = 10; // 1
    int b = 20; // 2
    int c = a + b; // 3
  

  这段代码中，a 和 b 不存在依赖关系，所以 1、2 可以进行重排序；c 依赖 a 和 b，所以 3 必须在 1、2 的后面执行。

• 控制依赖：

    public void use(boolean flag, int a, int b) {
    	 	if (flag) { // 1
    			int i = a * b; // 2
    		}
    }
  

  这段代码中，flag 和 i 存在控制依赖关系。当指令重排序后，2 这一步会将结果值写入重排序缓存中，当判断为 true 时，再把结果写入变量 i 中。

3.1.2 happens-before 原则

除了依靠 sychronized 和 volatile 关键字来保证原子性、可见性以及有序性之外，Java 内存模型还提供了 happens-before 原则来辅助保证程序执行的原子性、可见性以及有序性的问题，它是判断数据是否存在竞争、线程是否安全的依据，happens-before 原则内容如下：

• 程序顺序原则： 即在一个线程内必须保证语义串行性，也就是说按照代码顺序执行。
• 锁规则： 同一个锁的解锁操作一定发生在加锁操作之后。
• volatile 规则： 如果一个线程先去写一个 volatile 变量，另一个线程又去读这个变量，那么这个写操作的结果一定对读操作的这个线程可见。即保证不同的线程总是能够看到 volatile 变量的最新值。
• 传递性： A 先于 B ，B 先于 C 那么 A 必然先于 C。
• 线程启动规则： 线程的 start() 方法先于它的每一个动作。即如果在线程 A 中执行 B.start()（启动线程 B），那么 B.start() 操作先于线程 B 的任意操作。这条规则的含义是，线程 A 在启动子线程 B 之前对共享变量的修改结果对线程 B 可见。
• 线程终止规则： 线程的所有操作先于线程的终止。Thread.join() 方法的作用是等待当前执行的线程终止。如果线程 A 在执行过程中调用了 B.join() 方法，那么当线程 B 执行完后，线程 B 对共享变量的修改将对线程 A 可见。
• 线程中断规则： 对线程 interrupt() 方法的调用先发生于被中断线程的代码检测到中断事件的发生，就是说，响应中断一定发生在发起中断之后。
• 对象终结规则： 构造函数的结束（即一个对象初始化的完成）一定先于它的 finalize() 方法。

上述 8 条原则不需要使用 synchronized/volatile 即可达到效果。

3.1.3 内存屏障

内存屏障（Memory Barrier），又叫内存栅栏，是一条 CPU 指令，主要有两个作用：一个是保证特定操作的执行顺序，另一个是保证某些变量的内存可见性。

通俗一点的理解，内存屏障就相当于一道栅栏，把一段特定的程序分隔开，位于栅栏两边程序的执行顺序不能交换。也就是说，通过在指令间插入内存屏障，以禁止内存屏障前后的指令重排序。

3.2 JMM 提供的解决方案

JMM 就是用来解决多线程程序中存在的原子性、可见性以及有序性问题。在 Java 内存模型中提供了一套解决方案供 Java 工程师在开发过程中使用。

• 如原子性问题，除了 JVM 自身提供的对基本数据类型读写操作的原子性外，对于方法级别或者代码级别的原子性操作，可以使用 synchronized 关键字保证程序执行的原子性。（关于 synchronized 的详解，可以看博主的另一篇文章——synchronized 关键字）
• 对于由于工作内存与主内存同步延迟现象导致的可见性问题，可以使用 synchronized 关键字或者 volatile 关键字解决，它们都可以使一个线程修改后的变量立即对其它线程可见。
• 对于由于指令重排导致的可见性问题和有序性问题，可以使用 volatile 关键字解决，因为 volatile 的作用之一就是禁止指令重排序。

4. volatile 语义

volatile 是 Java 虚拟机提供的轻量级的同步机制，主要有两个作用：

• 保证线程可见性；
• 禁止指令重排序。

4.1 保证线程可见性

被 volatile 修饰的共享变量对所有线程总是可见的，也就是说当一个线程修改了这个被 volatile 修饰的共享变量，得到的新值可以立即被其它线程得知，但是对于 volatile 变量的运算操作在多线程环境下并不保证安全性。比如

public class VolatileVisibility {
    private volatile int i = 0;

    public void increase(){
        i++;
    }
}

如上述代码所示，共享变量 i 用 volatile 关键字修饰，变量 i 的任何改变都会立即反映到其它线程中。但是如果存在多条线程同时调用 increase() 方法的话，就会出现线程安全问题，毕竟 i++ 操作不具备原子性（该操作是先读取值，然后写回一个新值，分两步完成）。如果在线程 A 的读操作和写操作期间，线程 B 去读 i 的值，那线程 B 得到的依然是 i = 0，因为此时线程 A 还没有将 i = 1 写回主内存。这就是 volatile 只保证线程可见性，不保证线程安全性。

要保证线程安全性，就必须用 synchronized 关键字对 incerase() 方法进行修饰。synchronized 也能保证线程可见性，所以在用 synchronized 修饰方法之后，共享变量就不必再用 volatile 修饰了。如下：

public class VolatileVisibility {
    private int i = 0;

    public synchronized void increase(){
        i++;
    }
}

从上面的例子看出，如果要保证可见性的操作不是原子性的，就不能使用 volatile 关键字，而应该使用 synchronized 关键字，因为 volatile 不能保证这种情况的线程安全性；如果要保证可见性的操作也是原子性的，那使用 volatile 修饰变量也能达到线程安全的目的，如下

public class VolatileSafe {

    private volatile boolean close;

    public void close(){
        close = true;
    }

    public void doWork(){
        while (!close){
            System.out.println("safe....");
        }
    }
}

由于 colse() 方法中对于布尔型变量 close 的值的修改操作（赋值操作）属于原子性操作，因此可以通过使用 volatile 修饰变量 close，使得该变量对其它线程立即可见，从而达到线程安全的目的。

那么，JMM 是如何实现让 volatile 变量对其它线程立即可见的呢？

实际上，volatile 的内存可见性就是通过内存屏障的第二个特性实现的。当写一个 volatile 变量时，JMM 会把该线程对应的工作内存中的共享变量值刷新到主内存中；当读取一个 volatile 变量时，JMM 会把该线程对应的工作内存置为无效，那么该线程将只能从主内存中重新读取共享变量。volatile 变量正是通过这种写-读方式实现对其它线程可见。

4.2 禁止指令重排序

volatile 关键字的另一个作用就是禁止指令重排优化。一个典型的例子就是 DCL 单例模式（双重检验锁，Double-Check-Lock）。

面试题：DCL 单例模式在声明变量时要不要加 volatile 关键字？

DCL 单例的写法为：

public class SingleTon5 {

	// 注意这里没有加 volatile 关键字
    private static /*volatile*/ SingleTon5 instance;

    private SingleTon5(){}

    public static SingleTon5 getInstance(){
        if(instance == null){
            synchronized (SingleTon1.class){
                if(instance == null){
                    instance = new SingleTon5();
                }
            }
        }
        return instance;
    }
}

上述代码中有两次非空判断，所以被称为双重检验锁（Double-Check-Lock，DCL）。就代码层次而言是不存在线程安全问题的。但是实际上我们还要给 instance 变量加 volatile 关键字修饰，是为了解决 instance = new SingleTon5(); 可能存在的指令重排序问题。

因为 instance = new SingleTon5(); 这句代码编译后的指令实际上分为三步（伪代码）：

memory = allocate(); //1.分配对象内存空间（这时候对象会有一个默认值）
instance(memory);    //2.初始化对象（这时候给对象真正的赋值）
instance = memory;   //3.设置instance指向刚分配的内存地址

由于步骤 2 和步骤 3 不存在数据依赖关系，所以是允许重排序优化的。如果发生了如下的重排序

memory = allocate(); //1.分配对象内存空间（这时候对象会有一个默认值）
instance = memory;   //3.设置instance指向刚分配的内存地址
instance(memory);    //2.初始化对象（这时候给对象真正的赋值）

也就是给对象分配完内存空间之后，instance 就指向了刚分配的地址，这时候拿到的就是默认值，而不是真正要初始化的值，也就造成了线程安全问题。解决方法也很简单，给 instance 变量加 volatile 关键字禁止指令重排序即可。

所以完整的双重检验锁单例模式（DCL）的写法为

/**
 * 双重检验锁（DCL）
 */
public class DoubleCheckLock {

    private static volatile DoubleCheckLock instance;

    private DoubleCheckLock(){}

    public static DoubleCheckLock getInstance(){
        if(instance == null){
            synchronized (SingleTon1.class){
                if(instance == null){
                    instance = new DoubleCheckLock();
                }
            }
        }
        return instance;
    }
}