深入浅出 Java volatile：从硬件到 JMM 的完整剖析

前言：一个 Stack Overflow 上的真实困惑

在 Stack Overflow 上有一个经典问题：Java volatile keyword not working as expected。提问者遇到了一个令人困惑的现象，以下是他当时使用的代码：

public class Worker { private volatile int count = 0; private int limit = 1000000; // 增加到100万次，提高并发冲突概率 public static void main(String[] args) { Worker worker = new Worker(); worker.doWork(); } public void doWork() { Thread thread1 = new Thread(new Runnable() { public void run() { for (int i = 0; i < limit; i++) { count++; // 使用了 volatile，为什么还有问题？ } } }); thread1.start(); Thread thread2 = new Thread(new Runnable() { public void run() { for (int i = 0; i < limit; i++) { count++; } } }); thread2.start(); try { thread1.join(); thread2.join(); } catch (InterruptedException ignored) {} System.out.println("Count is: " + count); } }

实际运行结果（Java 17, Windows 11，连续5次执行）：

Count is: 1598976 Count is: 1449565 Count is: 1551467 Count is: 1622052 Count is: 1511579

预期结果：2000000（两个线程各自递增 100万次）
实际结果：始终小于 200万，且每次运行结果都不同

注意：如果你的环境下运行结果总是正确的 200万，说明并发冲突没有发生。这正是并发 Bug 的特点：不稳定、难以复现、依赖环境。在生产环境的高并发、多核 CPU 下，这个问题更容易暴露。

问题的困惑点：

• ✅count已经用volatile修饰了
• ✅ 理论上应该保证可见性
• ❌ 但最终结果却始终小于预期的 200万

这个真实案例揭示了一个关键认知误区：很多开发者以为volatile能解决所有并发问题，但实际上它并不保证原子性。

count++操作在字节码层面包含3个步骤：

1. getfield // 读取 count 的值 2. iadd // 执行加 1 操作 3. putfield // 写回 count

即使使用volatile，这三个步骤之间仍然可能被其他线程插入，导致典型的竞态条件：

结果：两次递增，count 只增加了 1！

这引出了更深层次的问题：

• volatile到底保证了什么？
• 它在 Java 内存模型中如何工作？
• 什么场景下必须用它，什么场景下不能用它？

本文将从硬件层面到 JMM（Java Memory Model）实现，系统性地剖析 volatile 的工作原理，并结合 JDK 17 源码和真实生产案例，让你彻底掌握 volatile 的使用。

文章脉络

一、问题起源 - CPU 缓存一致性与可见性危机

1.1 现代 CPU 的多级缓存架构

在理解 volatile 之前，必须先了解现代 CPU 的缓存架构。以 Intel i9 处理器为例：

为什么 CPU 必须使用多级缓存？

CPU 访问 L1 缓存的速度比访问主内存快很多倍！为了提高性能，CPU 必须使用多级缓存来减少内存访问延迟。但这也导致了缓存一致性问题。

1.2 缓存一致性问题的真实案例

假设两个线程同时操作共享变量count：

public class VisibilityProblem { private int count = 0; // 注意：没有 volatile // 线程1：写入者 public void writer() { count = 42; System.out.println("Thread1 写入 count = 42"); } // 线程2：读取者 public void reader() { int value = count; System.out.println("Thread2 读取 count = " + value); } }

执行时序分析：

关键问题：线程2 在 T4 时刻从自己的 L1 缓存读取到旧值0，而不是线程1 已经写入的42！

1.3 MESI 协议：硬件层面的解决方案

现代 CPU 使用MESI 协议（Modified、Exclusive、Shared、Invalid）来保证缓存一致性：

但问题是：普通变量的读写操作不会主动触发 MESI 协议的缓存失效通知！这就是volatile存在的意义。

二、硬件层面 - volatile 如何保证可见性

2.1 Lock 前缀指令：volatile 写的硬件实现

当你对 volatile 变量进行写操作时，Java 17 的 JIT 编译器会在生成的汇编代码中插入Lock 前缀指令。

实际测试代码：

public class VolatileTest { private volatile int volatileVar = 0; private int normalVar = 0; public void writeVolatile() { volatileVar = 100; // 会生成 Lock 指令 } public void writeNormal() { normalVar = 100; // 普通 mov 指令 } }

使用 JITWatch 查看汇编代码（Java 17 HotSpot VM）：

# volatile 写操作的汇编代码 writeVolatile(): mov $0x64, %eax ; 将 100 放入寄存器 lock addl $0x0, (%rsp) ; Lock 前缀指令（内存屏障） mov %eax, 0x10(%r10) ; 写入内存地址 # 普通写操作的汇编代码 writeNormal(): mov $0x64, %eax ; 将 100 放入寄存器 mov %eax, 0x14(%r10) ; 直接写入（无 Lock）

Lock 前缀指令的三大作用：

1. 立即刷新到主内存：绕过写缓冲区（Store Buffer），直接写入主内存
2. 使其他 CPU 缓存失效：通过总线锁定或缓存锁定触发 MESI 协议
3. 禁止指令重排序：作为内存屏障（Memory Barrier）

2.2 内存屏障：防止指令重排序

Java 17 的 volatile 实现依赖于四种内存屏障：

volatile 变量的内存屏障插入策略：

public class MemoryBarrierDemo { private int a = 0; private volatile int v = 0; private int b = 0; public void writer() { a = 1; // 普通写 // -------- StoreStore 屏障 -------- v = 2; // volatile 写 // -------- StoreLoad 屏障 -------- b = 3; // 普通写 } public void reader() { int dummy = v; // volatile 读 // -------- LoadLoad 屏障 -------- // -------- LoadStore 屏障 -------- int i = a; // 普通读 int j = b; // 普通读 } }

内存屏障的硬件实现（x86-64 架构）：

# StoreStore 屏障 sfence ; Store Fence，确保之前的写操作完成 # LoadLoad 屏障 lfence ; Load Fence，确保之前的读操作完成 # StoreLoad 屏障（最重的屏障） mfence ; Memory Fence，确保所有读写操作完成 lock addl $0x0, (%rsp) ; Lock 前缀也能实现 StoreLoad

三、JMM 视角 - happens-before 规则

3.1 Java 内存模型（JMM）的抽象

JMM 定义了线程与主内存之间的抽象关系：

JMM 的 8 个原子操作：

3.2 volatile 的 happens-before 规则

规则定义：对 volatile 变量的写操作 happens-before 后续对该变量的读操作。

代码验证：

public class VolatileHappensBefore { private int a = 0; private int b = 0; private volatile boolean flag = false; // 线程1 public void writer() { a = 1; // ① b = 2; // ② flag = true; // ③ volatile 写 } // 线程2 public void reader() { if (flag) { // ④ volatile 读 int i = a; // ⑤ 一定能看到 a=1 int j = b; // ⑥ 一定能看到 b=2 } } }

happens-before 链条：

① → ② → ③（volatile 写） ↓ (happens-before) ④（volatile 读）→ ⑤ → ⑥

保证结果：如果线程2 读取到flag=true，则一定能看到a=1和b=2！

四、实战案例一 - JDK 17 中的 volatile 应用

4.1 AbstractQueuedSynchronizer 的 state 字段

源码位置：java.util.concurrent.locks.AbstractQueuedSynchronizer

public abstract class AbstractQueuedSynchronizer extends AbstractOwnableSynchronizer implements java.io.Serializable { /** * 同步状态（volatile 保证可见性） */ private volatile int state; /** * 原子性地设置状态（CAS 操作） */ protected final boolean compareAndSetState(int expect, int update) { return STATE.compareAndSet(this, expect, update); } // VarHandle 实现（Java 17 推荐方式） private static final VarHandle STATE; static { try { MethodHandles.Lookup l = MethodHandles.lookup(); STATE = l.findVarHandle(AbstractQueuedSynchronizer.class, "state", int.class); } catch (ReflectiveOperationException e) { throw new ExceptionInInitializerError(e); } } }

为什么 state 必须是 volatile？

1. 可见性：当线程1 释放锁（修改 state=0）时，线程2 必须立即看到最新值
2. 有序性：防止 JIT 编译器将 state 的读写与临界区代码重排序

ReentrantLock 的使用示例：

public class ReentrantLockDemo { private final ReentrantLock lock = new ReentrantLock(); private int count = 0; public void increment() { lock.lock(); // 内部通过 CAS 修改 volatile state try { count++; // 临界区代码 } finally { lock.unlock(); // 将 state 改为 0（volatile 写） } } }

happens-before 保证：

线程1: lock.unlock()（volatile 写 state=0） ↓ (happens-before) 线程2: lock.lock()（volatile 读 state=0）→ 进入临界区

4.2 Thread.interrupt() 的中断标志

源码位置：java.lang.Thread

public class Thread implements Runnable { /** * 中断状态（volatile 保证实时性） */ private volatile boolean interrupted; /** * 中断线程 */ public void interrupt() { synchronized (interruptLock) { interrupted = true; // volatile 写 Interruptible b = nioBlocker; if (b != null) { b.interrupt(this); } } } /** * 检查中断状态 */ public boolean isInterrupted() { return interrupted; // volatile 读 } }

实际应用场景：

public class InterruptibleTask implements Runnable { @Override public void run() { while (!Thread.currentThread().isInterrupted()) { // volatile 读 // 执行任务 processData(); } cleanup(); // 清理资源 } private void processData() { // 业务逻辑 } private void cleanup() { System.out.println("任务已中断，正在清理资源..."); } } // 使用示例 Thread task = new Thread(new InterruptibleTask()); task.start(); Thread.sleep(5000); task.interrupt(); // volatile 写 interrupted=true

如果 interrupted 不是 volatile 会怎样？

• 主线程调用task.interrupt()后，工作线程可能长时间读取不到interrupted=true
• 导致任务无法及时停止，影响系统优雅关闭

五、实战案例二 - 双重检查锁定（DCL）

5.1 为什么 DCL 必须使用 volatile？

错误的单例实现：

public class Singleton { private static Singleton instance; // 缺少 volatile！ public static Singleton getInstance() { if (instance == null) { // ① 第一次检查 synchronized (Singleton.class) { if (instance == null) { // ② 第二次检查 instance = new Singleton(); // ③ 问题所在！ } } } return instance; } }

问题分析：指令重排序导致的半初始化对象

new Singleton()在字节码层面分为3步：

1. memory = allocate(); // 分配内存空间 2. ctorInstance(memory); // 初始化对象 3. instance = memory; // 设置 instance 指向内存地址

JIT 编译器可能重排序为：

1. memory = allocate(); // 分配内存 3. instance = memory; // 先赋值（此时对象未初始化！） 2. ctorInstance(memory); // 后初始化

并发问题时序：

正确的实现（使用 volatile）：

public class Singleton { private static volatile Singleton instance; // 必须 volatile！ private Singleton() {} public static Singleton getInstance() { if (instance == null) { synchronized (Singleton.class) { if (instance == null) { instance = new Singleton(); // volatile 写禁止重排序 } } } return instance; // volatile 读保证看到完全初始化的对象 } }

volatile 的作用：

1. 禁止重排序：StoreStore屏障确保步骤2 在步骤3 之前完成
2. 保证可见性：其他线程读取instance时一定是完全初始化的对象

5.2 实际测试验证

压力测试代码：

public class DCLTest { private static final int THREAD_COUNT = 100; public static void main(String[] args) throws InterruptedException { CountDownLatch latch = new CountDownLatch(THREAD_COUNT); Set<Singleton> instances = ConcurrentHashMap.newKeySet(); for (int i = 0; i < THREAD_COUNT; i++) { new Thread(() -> { instances.add(Singleton.getInstance()); latch.countDown(); }).start(); } latch.await(); System.out.println("创建的单例对象数量: " + instances.size()); // 正确输出：1（使用 volatile） // 错误输出：可能 > 1（不使用 volatile） } }

六、实战案例三 - 生产环境优雅停机

6.1 真实案例：Netty 框架的优雅停机

案例来源：Netty 4.1.xSingleThreadEventExecutor源码

Netty 是高性能网络框架，在其SingleThreadEventExecutor的实现中使用volatile实现了优雅停机机制。

核心原理（基于 Netty 源码逻辑）：

public abstract class SingleThreadEventExecutor extends AbstractScheduledEventExecutor implements OrderedEventExecutor { /** * 执行器状态（使用 volatile 保证可见性） * 状态值：ST_NOT_STARTED(1), ST_STARTED(2), ST_SHUTTING_DOWN(3), * ST_SHUTDOWN(4), ST_TERMINATED(5) * * 注：@SuppressWarnings("FieldMayBeFinal") 是因为 state 虽然看起来可以声明为 final， * 但实际上需要通过 VarHandle/Unsafe 进行 CAS 操作，不能使用 final */ @SuppressWarnings({ "FieldMayBeFinal", "unused" }) private volatile int state = ST_NOT_STARTED; @Override public Future<?> shutdownGracefully(long quietPeriod, long timeout, TimeUnit unit) { // 使用 CAS 操作更新状态（volatile 写） for (;;) { int oldState = state; if (oldState >= ST_SHUTTING_DOWN) { return terminationFuture(); } int newState = ST_SHUTTING_DOWN; if (STATE_UPDATER.compareAndSet(this, oldState, newState)) { break; } } // 触发优雅停机流程 return terminationFuture(); } @Override public void run() { // 事件循环主逻辑，检查 state 状态（volatile 读） for (;;) { // 检查是否需要停止 if (confirmShutdown()) { break; } // 处理任务 runAllTasks(); } } }

为什么必须使用volatile？

1. 多线程访问：

• 主线程调用shutdownGracefully()修改state
• EventExecutor线程在run()方法中读取state

• 如果不用volatile：

• EventExecutor线程可能一直读取缓存中的旧状态值
• 导致线程无法停止，优雅停机失效

1. 使用volatile后：

• 主线程写入state = ST_SHUTTING_DOWN→ 刷新到主内存
• EventExecutor线程读取state→ 从主内存获取最新值
• 立即看到状态变化，退出循环，完成优雅停机

如果 state 不是 volatile 会怎样？

• 某些线程可能长时间（甚至永久）读取不到状态变化
• 导致线程池无法正常关闭，系统升级失败
• 生产环境出现“僵尸线程”

总结

核心要点回顾

1. 硬件层面：volatile 通过Lock前缀指令实现缓存一致性，延迟约为普通变量的2-3倍
2. JMM 语义：volatile 提供 happens-before 保证，但不保证复合操作的原子性