理解 volatile

一、简介

volatile 不稳定的;易失的;易挥发的，易发散的;爆发性的，爆炸性的;易变的，无定性的，无常性的;短暂的
synchronized 是阻塞式同步，在线程竞争激烈的情况下会升级为重量级锁。而 volatile 可以说是 java 虚拟机提供的最轻量级的同步机制。但它同时不容易被正确理解，也至于在并发编程中很多程序员遇到线程安全的问题就会使用 synchronized。Java 内存模型告诉我们，各个线程会将共享变量从主内存中拷贝到工作内存，然后执行引擎会基于工作内存中的数据进行操作处理。线程在工作内存进行操作后何时会写到主内存中？这个时机对普通变量是没有规定的，而针对 volatile 修饰的变量给 java 虚拟机特殊的约定，线程对 volatile 变量的修改会立刻被其他线程所感知，即不会出现数据脏读的现象，从而保证数据的 可见性。
被 volatile 修饰的变量能够保证每个线程能够获取该变量的最新值，从而避免出现数据脏读的现象。

二、实现原理

volatile 是怎样实现了？

instance = new Instancce() //instance是volatile变量

在生成汇编代码时会在 volatile 修饰的共享变量进行写操作的时候会多出 Lock 前缀的指令。该指令在多核处理器下会发现什么事情了？主要有这两个方面的影响：

• 将当前处理器缓存行的数据写回系统内存；
• 这个写回内存的操作会使得其他 CPU 里缓存了该内存地址的数据无效。

为了提高处理速度，处理器不直接和内存进行通信，而是先将系统内存的数据读到内部缓存（L1，L2 或其他）后再进行操作，但操作完不知道何时会写到内存。如果对声明了 volatile 的变量进行写操作，JVM 就会向处理器发送一条 Lock 前缀的指令，将这个变量所在缓存行的数据写回到系统内存。但是，就算写回到内存，如果其他处理器缓存的值还是旧的，再执行计算操作就会有问题。所以，在多处理器下，为了保证各个处理器的缓存是一致的，就会实现缓存一致性协议，每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了，当处理器发现自己缓存行对应的内存地址被修改，就会将当前处理器的缓存行设置成无效状态，当处理器对这个数据进行修改操作的时候，会重新从系统内存中把数据读到处理器缓存里。因此，经过分析可以得出如下结论：

• Lock 前缀的指令会引起处理器缓存写回内存。
• 一个处理器的缓存回写到内存会导致其他处理器的缓存失效。
• 当处理器发现本地缓存失效后，就会从内存中重读该变量数据，即可以获取当前最新值。

volatile 变量通过这样的机制就使得每个线程都能获得该变量的最新值。

三、volatile 的 happens-before 关系

上述可知 volatile 变量可以通过缓存一致性协议保证每个线程都能获得最新值，即满足数据的 “可见性”。
并发分析的切入点分为两个核心，三大性质。两大核心：JMM 内存模型（主内存和工作内存）以及 happens-before；三条性质：原子性，可见性，有序性。

这里分析两个核心之一：volatile 的 happens-before 关系。
在六条 happens-before 规则中有一条是：volatile 变量规则：对一个 volatile 域的写，happens-before 于任意后续对这个 volatile 域的读。下面结合具体的代码，利用这条规则推导下：

public class VolatileExample {
    private int a = 0;
    private volatile boolean flag = false;

    public void writer() {
        a = 1;           //1
        flag = true;     //2
    }

    public void reader() {
        if (flag) {      //3
            int i = a;   //4
        }
    }
}

上面的实例代码对应的 happens-before 关系如下图所示：

加锁线程 A 先执行 writer 方法，然后线程 B 执行 reader 方法图中每一个箭头两个节点就代码一个 happens-before 关系，黑色的代表根据程序顺序规则推导出来，红色的是根据 volatile 变量的写 happens-before 于任意后续对 volatile 变量的读，而蓝色的就是根据传递性规则推导出来的。这里的 2 happen-before 3，同样根据 happens-before 规则定义：如果 A happens-before B, 则 A 的执行结果对 B 可见，并且 A 的执行顺序先于 B 的执行顺序，我们可以知道操作 2 执行结果对操作 3 来说是可见的，也就是说当线程 A 将 volatile 变量 flag 更改为 true 后线程 B 就能够迅速感知。

四、volatile 的内存语义

以上面的代码为例，假设线程 A 先执行 writer 方法，线程 B 随后执行 reader 方法，初始时线程的本地内存中 flag 和 a 都是初始状态，下图是线程 A 执行 volatile 写后的状态图。

当 volatile 变量写后，线程中本地内存中共享变量就会置为失效的状态，因此线程 B 再需要读取从主内存中去读取该变量的最新值。下图就展示了线程 B 读取同一个 volatile 变量的内存变化示意图。

从横向来看，线程 A 和线程 B 之间进行了一次通信，线程 A 在写 volatile 变量时，实际上就像是给 B 发送了一个消息告诉线程 B 你现在的值都是旧的了，然后线程 B 读这个 volatile 变量时就像是接收了线程 A 刚刚发送的消息。

4.1、内存语义的实现

为了性能优化，JMM 在不改变正确语义的前提下，会允许编译器和处理器对指令序列进行重排序。如果想阻止重排序要怎么办？答案是可以添加内存屏障。
JMM 内存屏障分为四类见下图。

Java 编译器会在生成指令系列时在适当的位置会插入内存屏障指令来禁止特定类型的处理器重排序。为了实现 volatile 的内存语义，JMM 会限制特定类型的编译器和处理器重排序，JMM 会针对编译器制定 volatile 重排序规则表：

"NO" 表示禁止重排序。为了实现 volatile 内存语义时，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。对于编译器来说，发现一个最优布置来最小化插入屏障的总数几乎是不可能的，为此，JMM 采取了保守策略：

在每个 volatile 写操作的前面插入一个 StoreStore 屏障；
在每个 volatile 写操作的后面插入一个 StoreLoad 屏障；
在每个 volatile 读操作的后面插入一个 LoadLoad 屏障；
在每个 volatile 读操作的后面插入一个 LoadStore 屏障。

需要注意的是：volatile 写是在前面和后面分别插入内存屏障，而 volatile 读操作是在后面插入两个内存屏障

StoreStore 屏障：禁止上面的普通写和下面的 volatile 写重排序；
StoreLoad 屏障：防止上面的 volatile 写与下面可能有的 volatile 读 / 写重排序
LoadLoad 屏障：禁止下面所有的普通读操作和上面的 volatile 读重排序
LoadStore 屏障：禁止下面所有的普通写操作和上面的 volatile 读重排序

下面以两个示意图进行理解

五、示例

public class VolatileExample {
    // 场景一：使用 volatile
    private static volatile boolean flag = false;
    private static int count = 0;

    public static void main(String[] args) throws InterruptedException {
        // 写线程
        new Thread(() -> {
            try {
                Thread.sleep(200);
                flag = true;  // 修改会立即对其他线程可见
                System.out.println("写线程修改 flag = true");
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }).start();

        // 读线程
        new Thread(() -> {
            while (!flag) {
                count++;  // 计数器
            }
            System.out.println("读线程发现 flag 变化，count = " + count);
        }).start();
    }
}

使用建议：

• 什么时候使用 volatile：
  • 一个线程写，多个线程读的场景
  • 需要保证可见性但不需要原子性的场景
  • 作为状态标志使用
• 什么时候不使用 volatile：
  • 需要保证原子性的场景（如计数器）
  • 复合操作的场景（如 i++）
  • 多线程写入的场景
• volatile 的局限性：
  • 不保证原子性
  • 不能替代锁
  • 可能带来性能开销