volatile与JMM深入解析：从内存可见性到并发实战

我从一个特别具体的场景开始聊你写了一段代码主线程把一个boolean标志位改成false想让子线程跳出while循环结果子线程像没看见一样继续死转CPU 飙到 100%。这种问题在 Java 并发编程里几乎人人都撞过而搞懂它的关键就是 volatile 和 Java 内存模型JMM。这两个概念我花了不少时间才算是啃透今天把整个来龙去脉、底层原理、实战用法和踩坑记录一次性讲清楚。这篇文章适合已经写过并发代码但总觉得“差口气”的 Java 开发者也适合正在准备 Java 面试、想看透 volatile 而不是背结论的朋友。1. 先搞清楚 volatile 到底解决了什么问题1.1 一个让我记忆深刻的线上问题先说个真实的例子。早些年我维护过一个定时任务调度系统里面有个常驻线程池主线程通过一个volatile boolean running来控制调度线程的启停。某次发布后运维反馈说任务停了但线程池还占着 CPU日志里也没报错。我把代码翻来覆去看逻辑没问题running也确实被改成false了可线程就是不停。后来用jstack一看调度线程卡在while (running)上状态是RUNNABLE但事实上主线程早就改了标志。去掉 volatile 试试问题复现子线程死活读不到新值。加上 volatile问题消失。就是那次我开始认真对待“内存可见性”这件事。这引出一个最基本的问题为什么一个线程改了共享变量另一个线程可能看不到1.2 volatile 的官方定义轻量级的同步机制volatile 是 Java 里最轻量的线程同步关键字它有三个核心语义保证可见性一个线程对 volatile 变量的写会立即对其他线程可见。保证有序性禁止编译器和 CPU 对该变量相关指令进行重排序。不保证原子性volatile 不解决复合操作的原子性问题比如count这种“读-改-写”三步操作。很多人背过这三条但不理解背后的机制。光记住结论没用面试官深挖两句就露馅。所以接下来得从 JMM 讲起。2. JMM 是理解 volatile 的地基2.1 从 CPU 缓存与缓存一致性说起要理解 JMM先得理解硬件。现代 CPU 和内存之间隔了好几层缓存L1、L2、L3。CPU 读写数据不直接访问内存而是先从缓存里拿缓存没命中才去内存加载。这个设计是为了填补 CPU 和内存之间几个数量级的速度差距。但多核 CPU 下问题来了两个核心各自缓存了同一份内存数据的副本其中一个核心改了它另一个核心还拿着旧副本。谁负责让这些副本保持同步这就需要缓存一致性协议比如经典的 MESI 协议后面细讲。Java 不在操作系统层直接控制这些也不可能为每个 CPU 架构单独写一份语义。于是 JMM 出现它定义了一套平台无关的内存规范让 Java 程序员不用关心底层是 x86 还是 ARM只要遵守 JMM 的规则就能写出跨平台正确的并发代码。一句话JMM 是 Java 层面的抽象规范底层由 CPU 缓存一致性协议、内存屏障等机制兜底实现。2.2 JMM 的抽象结构主内存与工作内存JMM 把内存抽象成两块主内存所有线程共享存放共享变量。工作内存每个线程私有可以理解为线程对共享变量的一份“本地副本”。线程 A 修改一个共享变量流程是先改自己工作内存里的副本再把副本写回主内存线程 B 要读到修改后的值需要从主内存把最新值重新加载到自己工作内存。中间任何一步“没来得及发生”B 就可能读到旧值。JMM 为此定义了 8 种原子操作用来约束“变量从主内存拷贝到工作内存、再从工作内存写回主内存”的完整流程lock、unlock、read、load、use、assign、store、write。平时写代码不会直接接触这些操作但理解这条数据通路对后面理解 volatile 为什么能“保证可见性”很有帮助。2.3 指令重排序的三个来源除了内存可见性JMM 还要管“顺序”。现代处理器和编译器为了提高性能会对指令重新排列只要不改变单线程执行结果就行这就是as-if-serial语义。重排序主要来自三个层面编译器优化JIT 编译器会根据热点代码做指令级优化可能交换无依赖语句的执行顺序。CPU 乱序执行处理器流水线允许后面不依赖前面结果的指令先执行。内存系统重排序写缓冲、存储转发等机制会让某条指令“看起来”被延迟或提前。单线程下重排序不影响结果多线程下重排序可能让另一个线程观察到完全不同的执行顺序。volatile 干的事之一就是把这些重排序限制住。3. volatile 的三大语义可见性、有序性和原子性边界3.1 可见性为什么普通变量会“读不到最新值”先看第一段代码public class VisibilityDemo { private static boolean running true; public static void main(String[] args) throws InterruptedException { Thread worker new Thread(() - { long count 0; while (running) { count; } System.out.println(worker stopped, count count); }); worker.start(); Thread.sleep(1000); running false; worker.join(); System.out.println(main done); } }这段代码在未开启 JIT 时可能能跑完但在真实服务器上JIT 编译后很常见的现象是while (running)被优化成直接读寄存器里的缓存值主线程的修改永远传不过来循环死转。给running加上 volatile 后线程每次循环都会重新从主内存读取最新值主线程写入false后子线程很快就能感知并退出。我用-XX:PrintAssembly看过加与不加 volatile 时的汇编代码区别非常明显。不加 volatile循环体里直接用寄存器值判断加了 volatile每次循环都会多一条带lock前缀的内存读取相关指令强制走缓存一致性流程。3.2 有序性volatile 是怎么限制重排序的volatile 的“禁止重排序”是通过内存屏障实现的。JMM 规定volatile 写操作前后插入屏障volatile 读操作后面插入屏障确保普通写不能越过它后面的 volatile 写。volatile 读不能越过它前面的普通读。volatile 写和读之间更不能乱换。典型的反面教材是双重检查锁DCL。看这段单例public class Singleton { private static Singleton instance; private Singleton() { } public static Singleton getInstance() { if (instance null) { synchronized (Singleton.class) { if (instance null) { instance new Singleton(); } } } return instance; } }问题出在instance new Singleton()不是原子操作它实质上有三个步骤分配内存空间调用构造函数初始化对象把引用赋值给 instance在编译器或 CPU 看来步骤 2 和 3 没有数据依赖可能被重排序成“先赋值引用、后执行构造函数”。这时候另一个线程在if (instance null)判断时发现 instance 不为空直接返回了一个还没构造完成的对象使用时就出问题。解决办法就是给 instance 加 volatilepublic class Singleton { private static volatile Singleton instance; private Singleton() { } public static Singleton getInstance() { if (instance null) { synchronized (Singleton.class) { if (instance null) { instance new Singleton(); } } } return instance; } }volatile 会禁止“构造函数初始化”和“赋值引用”之间的重排序确保对象发布时是完整构建好的。3.3 原子性volatile 无能为力的场景volatile 能管可见性和有序性但它管不了复合操作的原子性。最经典的例子就是计数器public class CounterDemo { private static volatile int count 0; public static void main(String[] args) throws InterruptedException { int threadCount 10; int incrementPerThread 10000; Thread[] threads new Thread[threadCount]; for (int i 0; i threadCount; i) { threads[i] new Thread(() - { for (int j 0; j incrementPerThread; j) { count; } }); threads[i].start(); } for (Thread t : threads) { t.join(); } System.out.println(count count); } }我本地跑过很多次结果基本都不到 100000经常是 40000、60000 这样的数字。原因很简单count是“读取-加一-写回”三步两个线程可能同时读到同一个旧值比如都读到 99各自加一后写回 100实际只增加了一次。volatile 只保证我写的这个值“别人看得见”不保证“写的过程别人没插一脚”。所以计数器需要原子性时得用synchronized或者AtomicIntegerprivate static AtomicInteger count new AtomicInteger(0); // 循环里count.incrementAndGet();注意一点AtomicInteger底层是用 CASCompare-And-Swap实现的它同样依赖 volatile 来保证字段可见。这说明 volatile 和原子类是互补关系而不是替代关系。4. volatile 的底层实现从字节码到内存屏障4.1 字节码层面的“隐形”有意思的是volatile 在字节码层面几乎没有痕迹。用javap -c看加了 volatile 的变量它的getstatic、putstatic指令和不加 volatile 时一模一样flags 里多一个ACC_VOLATILE标记而已。真正起作用的是 JIT 编译器。HotSpot 把带ACC_VOLATILE的字段访问翻译成带特殊前缀的机器指令。在 x86 平台上volatile 写的典型汇编码长这样mov 0x18(%rsi), %rax lock addl $0x0, (%rsp)那个lock前缀是核心。它会把当前处理器的写缓冲强制刷到缓存层级中同时让其他核心的对应缓存行失效。现代 x86 上lock配合具体指令实现的是“全屏障”效果成本比普通内存读写高一个数量级但换取的是语义正确性。4.2 内存屏障的类型与插入规则内存屏障分四种屏障类型含义作用LoadLoad读-读屏障禁止前面的读越过后面的读LoadStore读-写屏障禁止前面的读越过后面的写StoreStore写-写屏障禁止前面的写越过后面的写StoreLoad写-读屏障禁止前面的写越过后面的读是代价最高的一种JSR-133 规范给 volatile 定义了如下插入策略我用表格加文字说明volatile 写之前插入 StoreStore 屏障保证之前所有普通写都刷到主内存不会被重排到 volatile 写之后。volatile 写之后插入 StoreLoad 屏障防止后面普通读/写被重排到 volatile 写之前。volatile 读之后插入 LoadLoad 和 LoadStore 屏障防止后续普通读/写越过 volatile 读被提前执行。插个实用心得x86 是 TSOTotal Store Order模型LoadLoad、LoadStore、StoreStore 在 x86 上其实是被硬件天然保证的只有 StoreLoad 需要显式屏障。所以在 x86 上跑 Javavolatile 的实际成本主要在“写”这一侧。但 ARM、PowerPC 这类弱内存模型架构下四种屏障都可能有开销。跨架构部署服务的话别用“我在 x86 上测过没问题”来推断其他平台。4.3 缓存一致性协议 MESI 与 volatile 的关系再往底层挖一层就是缓存一致性协议。经典的是 MESI每个缓存行有四种状态状态全称含义MModified本核已修改与主内存不一致其他核不可见EExclusive本核独占与主内存一致其他核没有副本SShared多个核都有副本与主内存一致IInvalid已失效需要重新从主内存加载当一个核要写一个处于 S 状态的缓存行时会向其他核广播“失效”消息其他核收到后把本地副本置为 I 状态下次读取必须重新加载。这样就保证了“某个核写入的结果最终其他核能看到”。但注意MESI 保证的是“最终一致性”不是绝对实时。在有写缓冲Store Buffer的 CPU 上一个核写入后数据可能先在写缓冲里还没广播失效消息读核如果从无效队列里读也可能拿到旧值。x86 上lock前缀和内存屏障的作用就是把写缓冲“推”出去并确保读的一方不会用旧数据应付。所以严格说volatile 的可见性 ≠ “MESI 瞬间完成同步”而是“JMM 通过内存屏障强制在需要的时间点完成缓存同步”。理解这个区分能解释很多奇怪现象比如为什么循环里不加 volatile 时JIT 优化后线程迟迟看不到标志位变化。5. volatile 的典型应用场景与实战5.1 场景一状态标志与线程开关这是 volatile 最标准、最安全的用法一个线程写、多个线程读不涉及复合操作。比如优雅停机public class GracefulShutdown { private volatile boolean running true; public void start() { Thread worker new Thread(() - { while (running) { doWork(); } System.out.println(worker exit); }); worker.start(); } public void stop() { running false; } private void doWork() { // 业务处理 } }这种场景下 volatile 完美胜任写线程只有一个比如控制台、运维接口触发stop()读线程可以有很多各读各的互不干扰。再如双重检查锁、连接池初始化、服务降级开关、灰度切换开关本质上都是“单写多读”的状态模式都适合用 volatile。5.2 场景二双重检查锁单例前面 DCL 已经演示过了。补充一个细节JDK 5 之前的 JMM 对 volatile 的语义支持不完整DCL 加了 volatile 也可能有问题。JDK 5 开始JSR-133 强化了 volatile 语义DCL volatile 才真正成为可靠写法。这也是很多老项目里 DCL 单例要么不用、要么用枚举或静态内部类的原因。更稳的替代方案是静态内部类public class Singleton { private Singleton() { } private static class Holder { private static final Singleton INSTANCE new Singleton(); } public static Singleton getInstance() { return Holder.INSTANCE; } }它利用类加载时的初始化锁天然线程安全也不依赖 volatile。但有些场景必须显式控制单例的创建时机DCL volatile 的地位依然不可替代。5.3 场景三AQS 里的 volatile state如果你读过java.util.concurrent的源码会发现AbstractQueuedSynchronizerAQS核心字段就是 volatile 的private volatile int state;ReentrantLock、Semaphore、CountDownLatch都是基于 AQS 实现的。它们的加锁、解锁本质上是 CAS 修改这个state字段。CAS 本身保证原子性但它需要 volatile 保证前一个线程对 state 的修改对后一个尝试 CAS 的线程可见。可以说整个 JUC 包的地基就是 volatile CAS。不注意这一点读 AQS 源码会总觉得隔层纱。还有AtomicInteger的源码value是volatile int配合Unsafe.compareAndSwapInt实现无锁自增。这也解释了我前面说的“Atomic 类依赖 volatile”。5.4 场景四发布不可变对象如果一个对象的所有字段都是 final并且引用发布时对状态做了正确同步那么即使引用本身是普通变量其他线程也可能安全读到它的状态。但发布时机如果没控制好就有风险。用 volatile 修饰对象引用可以保证“对象引用对读者可见时对象内部的构造效果也对读者可见”。这是我做配置中心客户端时的经验配置对象整体构建完成后一次性发布到一个 volatile 字段上读取方直接读这个字段拿完整配置不需要额外加锁。核心逻辑就是利用 volatile 写和 volatile 读之间的 happens-before 关系。6. volatile 与 synchronized、Atomic 类怎么选6.1 语义与性能对照先给张硬核对照表方便直接抄对比项volatilesynchronizedAtomicInteger可见性保证保证保证原子性不保证保证临界区保证单变量操作有序性插入内存屏障锁的互斥与内存屏障CAS 配合 volatile阻塞不阻塞可能阻塞自旋不阻塞开销读写有屏障开销锁升级到重量级后开销大高竞争下自旋重试开销大适用场景单写多读状态标志、发布不可变对象复合操作、临界区、多写场景计数器、单变量自增、状态原子更新6.2 常见误区哪些代码加了 volatile 还是错的我在给团队做代码评审时经常看到这几类“假 volatile 保护”场景一volatile 修饰 List 或 Map。volatile 只保证引用本身可见不保证集合内部元素的线程安全。volatile ListString list线程 Alist.add(...)线程 B 遍历 list该出并发问题还是出。场景二先判断后操作。if (flag) { doSomething(); }如果doSomething()需要基于 flag 做复合业务flag 是 volatile 也白搭判断和执行之间别的线程可能已经把 flag 改了。场景三volatile boolean 延迟。状态位确实是单写多读但写线程在修改前还有一堆耗时操作读线程提前读到旧值导致业务短暂不一致。这不算 volatile 的错是业务设计问题。6.3 面试高频陷阱题这块是 Java 面试必考题把逻辑理清楚volatile 能保证原子性吗不能。count是三步操作volatile 管不了要用AtomicInteger或锁。volatile 和 synchronized 的区别volatile 是无锁轻量同步只能修饰变量保证可见性和有序性synchronized 是锁保证互斥、可见性和原子性能修饰方法和代码块。volatile 的 happens-before 规则是什么对一个 volatile 变量的写先行发生于任意线程后续对这个变量的读。简单说写完 volatile后面的读一定能看到写的结果。为什么 DCL 要加 volatile防止new操作中“分配内存、初始化、赋值引用”的重排序导致其他线程拿到未初始化完成的对象。volatile 修饰数组有没有用只保证数组引用可见不保证元素可见。要安全发布数组里的元素得配锁或使用AtomicReference等。把这些点串起来面试时就不怕深挖了。关键是始终带着“可见性、有序性、原子性”三条线去答。7. 我踩过的坑与排查实录7.1 坑一加了 volatile循环还是死等有次写完优雅停机真机上子线程还是不停。先确认running确实加了 volatilejstack也看了线程状态。后来发现原因子线程里while (running)如果执行体doWork()耗时极长循环判断频率很低明明标志位早改了但它在执行完一轮长任务才会检查。这不是可见性问题是业务轮询粒度问题。解决思路核心循环里用Thread.currentThread().isInterrupted()或把长任务切成小任务块在块间检查标志位。volatile 只负责“你看到了”不负责“你快去看”。7.2 坑二volatile 计数器依然丢数据这个几乎是新手必踩。计数器场景用了 volatile测试时数据不对第一反应是“volatile 是不是失效了”其实是原子性问题。排查办法很简单把count换成AtomicInteger.incrementAndGet()或者用synchronized包住自增数据立马正确。经验教训碰到“多个线程同时写一个变量”的场景先别怀疑可见性先怀疑原子性。7.3 坑三DCL 去掉 volatile 后到底会不会出事理论上会出事但实际复现很难。原因instance new Singleton()的重排序需要特定 JIT 编译条件开启编译优化后才可能出现而且需要另一个线程恰好卡在“判断 instance 非空、返回未初始化对象”的时间窗口。我之前写过一段压力测试跑了很久也没复现但不代表安全。并发问题本来就是概率问题线上出一次就够受的。所以结论非常明确DCL 必须加 volatile。不要拿“我跑过没出问题”当理由。7.4 排查工具与经验排查并发问题我这几年常用的工具链jstack看线程状态和阻塞位置比如死循环的线程会显示在while对应行。hsdis -XX:PrintAssembly本地 JVM 开启汇编输出看 volatile 访问是否生成了lock前缀指令。需要额外装 hsdis 库做底层验证时很有用。JMH对比 volatile、synchronized、AtomicInteger 在真实负载下的吞吐和延迟。别靠感觉谈性能用数据说话。Arthas线上动态查看类加载的字段值可以watch某个 volatile 字段的读写确认到底改没改、读没读到。我自己的习惯是碰到摸不着头脑的“数据偶尔不对”先写一个最小复现程序用多线程压测复现再逐步化简到只剩一个变量一个循环然后决定用 volatile、锁还是原子类。绝大多数并发问题最小化之后都比想象中简单。结尾的一点个人体会把 volatile 和 JMM 完整吃透之后最大的变化不是面试题会答了而是写并发代码时有了直觉看到共享变量第一反应不是“加个 volatile 试试”而是先问自己是单写多读还是多写多读是否涉及复合操作读和写之间有没有 happens-before 关系。volatile 是一把精密的工具用对场景它极其优雅用错场景它会制造最隐蔽的线上事故。我最后再分享一个小技巧在代码评审时所有共享变量都要强制回答三个问题——谁写、谁读、读写之间靠什么同步。这三个问题答不上来这段代码就别想合入。这套思路比记住任何一条 JMM 条款都管用。