当前位置：首页 > news >正文

第六章 volatile 与 JMM

news 2026/4/14 21:18:31

6.1 被 volatile 修饰的变量有两大特点

特点：

可见性
有序性：有排序要求，有时需要禁重排

内存语义：

当写一个 volatile 变量时，JMM 会把该线程对应的本地内存中的共享变量值立刻刷新回主内存中
当读一个 volatile 变量时，JMM 会把该线程对应的本地内存设置为无效，重新回到主内存中读取最新共享变量的值
所以 volatile 的写内存语义时直接刷新到主内存中，读的内存语义时直接从主内存中读取

volatile 凭什么可以保证可见性和有序性？

内存屏障 Memory Barrier

6.2 内存屏障（面试重点必须拿下）

6.2.1 生活 case

没有管控，顺序难保

设定规则，禁止乱序 ------> 上海南京路武警当红灯

再说 volatile 两大特性：

可见性：写完后立即刷新回主内存并及时发出通知，大家可以去主内存拿最新版，前面的修改对后面所有线程可见
有序性（禁止重排）：重排序是指编译器和处理器为了优化程序性能而对指令序列进行重新排序的一种手段，有时候会改变程序语句的先后顺序，若不存在数据依赖关系，可以重排序；存在数据依赖关系，禁止重排序；但重排序后的指令绝对不能改变原有的串行语义！这点在并发设计中必须要重点考虑！

6.2.2 是什么

内存屏障（也称内存栅栏，屏障指令等）是一类同步屏障指令，是 CPU 或编译器在堆内存随机访问的操作中的一个同步点，使得此点之前的所有读写操作都执行后才可以执行此点之后的操作，避免代码重排序。内存屏障其实就是一种 JVM 指令，Java 内存模型的重排规则会要求 Java 编译器在生成 JVM 指令时插入特定的内存屏障指令，通过这些内存屏障指令，volatile 实现了 Java 内存模型中的可见性和有序性（禁重排），但 volatile 无法保证原子性

内存屏障之前的所有写操作都要回写到主内存
内存屏障之后的所有读操作都能获得内存屏障之前的所有写操作的最新结果（实现了可见性）

写屏障（Store Memory Barrier）：告诉处理器在写屏障之前将所有存储在缓存（store buffers）中的数据同步到主内存，也就是说当看到 store 屏障指令，就必须把该指令之前的所有写入指令执行完毕才能继续往下执行

读屏障（Load Memory Barrier）：处理器在读屏障之后的读操作，都在读屏障之后执行。也就是说在 Load 屏障指令之后就能保证后的读取数据指令一定能够读取到最新的数据

因此重排序时，不允许把内存屏障之后的指令重排序到内存屏障之前，一句话，对一个 volatile 变量的写，先行发生于任意后续对这个 volatile 变量的读，也叫写后读

6.2.3 内存屏障分类

粗分两种：

读屏障（Load Barrier）：在读指令之前插入读屏障，让工作内存或 CPU 告诉缓存当中的缓存数据失效，重新回到主内存中获取最新数据
写屏障（Store Barrier）：在写指令之后插入写屏障，强制把缓冲区的数据刷回到主内存中

细分四种：

屏障类型	指令示例	说明
LoadLoad	Load1;LoadLoad;Load2	保证 Load1 的读取操作在 Load2 及后续读取操作之前执行
StoreStore	Store1;StoreStore;Store2	在 Store2 及其后的写操作执行前，保证 Store1 的写操作已经刷新到主内存
LoadStore	Load1;LoadStore;Store2	在 Store2 及其后的写操作执行前，保证 Load1 的读操作已经结束
StoreLoad	Store1;StoreLoad;Load2	保证 Store1 的写操作已经刷新到主内存后，Load2 及其后的读操作才能执行

6.2.4 困难内容

什么叫保证有序性？-------> 通过内存屏障禁重排

重排序有可能影响程序的执行和实现，因此，我们有时候希望告诉 JVM 别自动重排序，我这里不需要重排序，一切听我的
对于编译器的重排序，JMM 会根据重排序的规则，禁止特定类型的编译器重排序
对于处理器的重排序，Java 编译器在生成指令序列的适当位置，插入内存屏障指令，来禁止特定类型的处理器排序

happens-before 之 volatile 变量规则

第一个操作	第二个操作：普通读写	第二个操作：volatile 读	第二个操作：volatile 写
普通读写	可以重排	可以重排	不可以重排
volatile 读	不可以重排	不可以重排	不可以重排
volatile 写	可以重排	不可以重排	不可以重排

当第一个操作为 volatile 读时，无论第一个操作是什么，都不能重排序，这个操作保证了 volatile 读之后的操作不会被重排到 volatile 读之前
当第一个操作为 volatile 写时，第二个操作为 volatile 读时，不能重排
当第二个操作为 volatile 写时，无论第一个操作是什么，都不能重排序，这个操作保证了 volatile 写之前的操作不会被重排到 volatile 写之后

JMM 就将内存屏障插入策略分为 4 种规则

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

6.3 volatile 特性

6.3.1 保证可见性

保证不同线程对某个变量完成操作后结果及时可见，即该共享变量一旦改变所有线程立即可见

不加 volatile，没有可见性，程序无法停止
加了 volatile，保证可见性，程序可以停止

public class VolatileSeeDemo {//    private static boolean flag = true;private static volatile boolean flag = true;/*** 运行结果：* t1	 -------come in* main	 -------修改flag:false* t1	 -------flag被修改为false，程序停止*/public static void main(String[] args) {new Thread(() -> {System.out.println(Thread.currentThread().getName() + "\t -------come in");while (flag) {}System.out.println(Thread.currentThread().getName() + "\t -------flag被修改为false，程序停止");}, "t1").start();//暂停几秒钟线程try {TimeUnit.SECONDS.sleep(2);} catch (InterruptedException e) {e.printStackTrace();}flag = false;System.out.println(Thread.currentThread().getName() + "\t -------修改flag:" + flag);}}

volatile 变量的读写过程

read（读取）：作用于主内存，将变量的值从主内存传输到工作内存，主内存到工作内存
load（加载）：作用于工作内存，将 read 从主内存传输的变量值放入工作内存变量副本中，即数据加载
use（使用）：作用于工作内存，将工作内存变量副本的值传递给执行引擎，每当 JVM 遇到需要该变量的字节码指令时会执行该操作
assign（赋值）：作用于工作内存，将从执行引擎接收到的值赋值给工作内存变量，每当 JVM 遇到一个给变量赋值字节码指令时会执行该操作
store（存储）：作用于工作内存，将赋值完毕的工作变量的值写回给主内存
write（写入）：作用于主内存，将 store 传输过来的变量值赋值给主内存中的变量

由于上述 6 条只能保证单条指令的原子性，针对多条指令的组合性原子保证，没有大面积加锁，所以 JVM 提供了另外两个原子指令：

lock：作用于主内存，将一个变量标记为一个线程独占的状态，只是写时候加锁，就只是所里写变量的过程
unlock：作用于主内存，把一个处于锁定状态的变量释放，然后才能被其他线程占用

6.3.2 没有原子性

volatile 变量的复合操作不具有原子性

public class VolatileNoAtomicDemo {/*** 运行结果：* number:9856*/public static void main(String[] args) {MyNumber myNumber = new MyNumber();for (int i = 0; i < 10; i++) {new Thread(() -> {for (int j = 0; j < 1000; j++) {myNumber.addPlusPlus();}}, String.valueOf(i)).start();}try {TimeUnit.SECONDS.sleep(2);} catch (InterruptedException e) {e.printStackTrace();}System.out.println("number:" + myNumber.number);}}class MyNumber {volatile int number;public /*synchronized*/ void addPlusPlus() {number++;}}

对于 volatile 变量具备可见性，JVM 只是保证从主内存加载到线程工作内存的值是最新的，也仅仅是数据加载时是最新的。但是多线程环境下，“数据计算”和“数据赋值”操作可能出现多次，若数据在加载之后，若主内存 volatile 修饰变量发生修改之后，线程工作内存的操作将会作废去读主内存最新值，操作出现写丢失问题。即各线程私有内存和主内存公共内存中变量不同步，进而导致数据不一致。由此可见 volatile 解决的是变量读时的可见性问题，但无法保证原子性，对于多线程修改主内存共享变量的场景必须加锁同步
至于怎么去理解这个写丢失的问题，就是在将数据读取到本地内存到写回主内存中有三个步骤：数据加载 ------> 数据计算 ------> 数据赋值，如果第二个线程在第一个线程读取旧值与写回新值期间读取共享变量的值，那么第二个线程将会与第一个线程一起看到同一个值，并执行自己的操作，一旦其中一个线程 volatile 修饰的变量先行完成操作刷回主内存后，另一个线程会作废自己的操作，然后重新去读取最新的值再进行操作，这样的花，它自身的那一次操作就丢失了，这就造成了线程安全失败，因此，这个问题需要使用 synchronized 修饰以保证线程安全性

结论：volatile 变量不适合参与到依赖当前值的运行，如 i++，i = i + 1 之类的，通常用来保存某个状态的 boolean 值或者 int 值，也正是由于 volatile 变量只嗯呢该保证可见性，在不符合以下规则的运算场景中，我们仍然要通过加锁来保证原子性

运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值
变量不需要与其他的状态变量共同参与不变约束

面试回答为什么不具备原子性？

举例 i++ 的例子，在字节码文件中，i++ 分为三部，间隙期间不同步非原子操作

对于 volatile 变量，JVM 只是保证从主内存加载到线程工作内存中的值是最新的，也就是数据加载时是最新的，如果第二个线程在第一个线程读取旧值和写回新值期间读取 i 的域值，也就造成了线程安全问题

6.3.3 指令禁重排

在每一个 volatile 写操作前面插入一个 StoreStore 屏障 ---> StoreStore 屏障可以保证在 volatile 写之前，其前面所有的普通写操作都已经刷新到主内存中
在每一个 volatile 写操作后面插入一个 StoreLoad 屏障 ----> StoreLoad 屏障的作用是避免 volatile 写与后面可能有的 volatile 读/写操作重排序
在每一个 volatile 读操作后面插入一个 LoadLoad 屏障 ----> LoadLoad 屏障用来禁止处理器把上面的 volatile 读与下面的普通读重排序
在每一个 volatile 读操作后面插入一个 LoadStore 屏障 ----> LoadStroe 屏障用来禁止处理器把上面的 volatile 读与下面的普通写重排序

案例说明（volatile 读写前或后加了屏障保证有序性）：

6.4 如何正确使用 volatile

单一赋值可以，但是含复合运算赋值不可以（i++之类的）

volatile int a = 10;
volatile boolean flag = true;

状态标志，判断业务是否结束

作为一个布尔状态标志，用于指示发生了一个重要的一次性时间，例如完成初始化或任务结束

public class UseVolatileDemo {private volatile static boolean flag = true;public static void main(String[] args) {new Thread(() -> {while (flag) {//do something}}, "t1").start();try {TimeUnit.SECONDS.sleep(2);} catch (InterruptedException e) {e.printStackTrace();}new Thread(() -> {flag = false;}, "t2").start();}}

开销较低的读，写锁策略

当读远多于写，结合使用内部锁和 volatile 变量来减少同步的开销

原理：利用 volatile 保证读操作的可见性，利用 synchronized 保证符合操作的原子性

public class Counter {private  volatile int value;/*** 利用 volatile 保证读取操作的可见性*/public int getValue() {return value;}/*** 利用 synchronized 保证复合操作的原子性*/public synchronized int increase() {return value++;}}

DCL 双端锁的发布

问题描述：首先设定一个加锁的单例模式场景

public class SafeDoubleCheckSingleton {private static SafeDoubleCheckSingleton singleton;/*** 私有化构造方法*/private SafeDoubleCheckSingleton() {}/*** 双重锁设计*/public static SafeDoubleCheckSingleton getInstance() {if (singleton == null) {//1.多线程并发创建对象时，会通过加锁保证只有一个线程能创建对象synchronized (SafeDoubleCheckSingleton.class) {if (singleton == null) {//隐患：多线程环境下，由于重排序，该对象可能还未完成初始化就被其他线程获取singleton = new SafeDoubleCheckSingleton();}}}//2.对象创建完毕，执行 getInstance 将不需要获取锁，直接返回创建对象return singleton;}}

在单线程环境下（或者说正常情况下），在“问题代码处”，会执行以下操作，能保证获取到已完成初始化的实例

隐患：在多线程环境下，在“问题代码处”，会执行以下操作，由于重排序导致 2，3 乱序，后果就是其他线程得到的是 null 而不是完成初始化的对象，其中第 3 步中实例化分多步执行（分配内存空间、初始化对象、将对象指向分配的内存空间），某些编译器为了性能，会将第 2 步和第 3 步重排序，这样某个线程可能会获得一个未完全初始化的实例

多线程下的解决方案：加 volatile 修饰

public class SafeDoubleCheckSingleton {//通过 volatile 声明，实现线程安全的延迟初始化private volatile static SafeDoubleCheckSingleton singleton;/*** 私有化构造方法*/private SafeDoubleCheckSingleton() {}/*** 双重锁设计*/public static SafeDoubleCheckSingleton getInstance() {if (singleton == null) {//1.多线程并发创建对象时，会通过加锁保证只有一个线程能创建对象synchronized (SafeDoubleCheckSingleton.class) {if (singleton == null) {//隐患：多线程环境下，由于重排序，该对象可能还未完成初始化就被其他线程获取//解决隐患原理：利用 volatile ，禁止“初始化对象”（2）和“设置 singeton 指向内存空间（3）”的重排序singleton = new SafeDoubleCheckSingleton();}}}//2.对象创建完毕，执行 getInstance 将不需要获取锁，直接返回创建对象return singleton;}}

6.5 本章最后的小结

6.5.1 volatile 可见性

volatile 关键字保证可见性	对一个被 volatile 关键字修饰的变量
1	写操作的话，这个变量的最新值会立刻刷新回到主内存中
2	读操作的话，总是能够读取到这个变量的最新值，也就是这个变量最后被修改的值
3	当某个线程收到通知，去读取 volatile 修饰的变量的值的时候，线程私有工作内存的数据失效，需要重新回到主内存中去读取最新的数据