1. 从一个诡异的死循环说起如果你写过Java多线程代码大概率遇到过这样一种情况程序逻辑看起来完全正确但线程就是卡在某个循环里出不来加一行打印语句它又正常了。这种“薛定谔的Bug”背后十有八九是内存可见性在作祟。这篇文章要聊的volatile关键字就是Java里解决可见性问题的第一把交椅。它不像synchronized那样能保证原子性也不像ReentrantLock那样功能丰富但它在特定场景下轻量、高效是并发编程里绕不开的基础设施。如果你正在学JMMJava内存模型、正在被面试官追问volatile和synchronized的区别、或者正在排查一个多线程环境下“改了值但另一个线程读不到”的诡异问题那这篇内容就是写给你的。我会从CPU缓存架构讲起把可见性问题的根因一层层剥开然后落到volatile的底层实现、使用场景、常见误区和实测验证上。中间会穿插大量我实际踩过的坑和调试经验尽量让你看完之后不仅知道“怎么用”更清楚“为什么必须这么用”。2. 可见性问题的根因CPU缓存与JMM的抽象2.1 一个不加volatile的经典翻车现场先看一段代码这段代码我最早是在一个后台任务调度模块里遇到的简化后大概长这样public class VisibilityDemo { private static boolean running true; public static void main(String[] args) throws InterruptedException { Thread worker new Thread(() - { while (running) { // 执行任务 } System.out.println(worker thread stopped); }); worker.start(); Thread.sleep(1000); running false; System.out.println(main thread set running false); } }直觉上主线程把running改成false之后worker线程应该马上跳出循环并打印“worker thread stopped”。但实际跑起来你会发现worker线程很可能永远卡在while循环里主线程那句打印倒是正常输出了。更诡异的是如果你在while循环里加一句System.out.println(running)程序就正常退出了。这不是玄学这是内存可见性问题在真实环境里的表现。2.2 从CPU缓存层级理解“为什么读不到”要搞清楚这个问题得先理解现代计算机的内存架构。CPU的执行速度远远快于主内存的读写速度为了弥补这个差距硬件层面引入了多级缓存层级典型容量访问延迟归属寄存器几十到几百字节约0.3ns单核私有L1 Cache32KB~64KB约1ns单核私有L2 Cache256KB~512KB约3~10ns单核私有L3 Cache数MB到数十MB约10~30ns多核共享主内存GB级别约60~100ns全局共享当worker线程第一次读取running变量时它会把值从主内存加载到自己的工作内存对应CPU缓存和寄存器的抽象。之后每次循环判断它可能直接从缓存里读而不是回主内存重新加载。主线程修改running false时写的是主内存或者主线程自己的缓存再刷回主内存但worker线程的缓存里还是旧的true于是死循环就出现了。这就是可见性问题的本质一个线程对共享变量的修改另一个线程不一定能立刻看到。2.3 JMM给出的抽象模型Java内存模型JMM把硬件的这套缓存机制抽象成了“主内存”和“工作内存”的概念。每个线程有自己的工作内存共享变量存在主内存里。线程对变量的所有操作都必须在工作内存中进行不能直接读写主内存。JMM定义了8种原子操作来规范主内存和工作内存之间的交互lock、unlock、read、load、use、assign、store、write。这套模型本身不保证一个线程的写操作何时对其他线程可见也不保证多线程执行的顺序。volatile、synchronized、final这些关键字本质上都是在JMM的规则框架下对可见性和有序性做出额外承诺。注意JMM是一个规范不是物理实现。不同JVM、不同CPU架构下的具体行为可能有差异但都必须满足JMM定义的语义。3. volatile到底做了什么可见性与有序性的双重承诺3.1 可见性保证的底层机制给running加上volatile之后程序就能正常退出了。这背后发生了什么从JMM层面看volatile变量的写操作会立刻刷回主内存读操作会直接从主内存加载。但这只是抽象描述真正的实现依赖CPU提供的内存屏障指令。以x86架构为例volatile写操作前面会插入一个StoreStore屏障后面插入一个StoreLoad屏障volatile读操作前面插入LoadLoad屏障后面插入LoadStore屏障。这些屏障指令的作用是禁止特定类型的指令重排序并强制将写缓冲区中的数据刷到缓存一致性协议能看到的层级。用生活化的类比普通变量像是你把文件存在自己电脑的桌面上别人看不到volatile变量像是你每次改完都立刻上传到共享网盘别人每次读都从网盘拉最新版本。代价是每次读写都要走网络比本地操作慢。3.2 有序性保证禁止指令重排序volatile的第二个承诺是禁止指令重排序。编译器和CPU为了优化性能会在不影响单线程语义的前提下调整指令执行顺序。但在多线程环境下这种重排序可能导致意想不到的结果。经典的例子是双重检查锁定DCL单例模式public class Singleton { private static volatile Singleton instance; public static Singleton getInstance() { if (instance null) { synchronized (Singleton.class) { if (instance null) { instance new Singleton(); } } } return instance; } }instance new Singleton()这行代码在字节码层面大致分三步分配内存、初始化对象、将引用指向内存地址。如果没有volatile步骤2和步骤3可能被重排序。另一个线程可能在instance已经非null但对象还没初始化完成时拿到引用使用时就会出问题。volatile通过插入内存屏障禁止了这种重排序。3.3 volatile不保证原子性这是最容易踩的坑。很多人以为volatile能替代synchronized实际上它只保证可见性和有序性不保证原子性。看下面这个例子public class Counter { private volatile int count 0; public void increment() { count; } }count看起来是一行代码实际上包含读取、加一、写回三个操作。多个线程同时执行时即使count是volatile的最终结果也可能小于预期。因为读取和写回之间可能被其他线程插入。要保证原子性得用synchronized、AtomicInteger或者LongAdder。volatile只适合“一写多读”或者“状态标志位”这类场景。4. 内存屏障与happens-beforevolatile的规则边界4.1 happens-before规则中的volatile条款JMM用happens-before关系来描述两个操作之间的可见性保证。如果操作A happens-before 操作B那么A的结果对B可见。volatile相关的规则有两条volatile写 happens-before 后续任意线程对该volatile变量的读。这意味着一个线程写了volatile变量后另一个线程读这个变量时能看到写之前的所有操作结果。volatile读 happens-before 后续对该volatile变量的写。这条相对少用但理解它有助于把握完整的语义。这两条规则组合起来让volatile变量成了一个“同步点”。写线程在写volatile之前的所有操作对读线程在读volatile之后的所有操作都可见。4.2 四种内存屏障的实际作用JMM定义了四种内存屏障volatile的读写会插入不同的屏障组合屏障类型作用插入位置LoadLoad禁止上面的普通读与下面的volatile读重排序volatile读之后StoreStore禁止上面的普通写与下面的volatile写重排序volatile写之前LoadStore禁止上面的volatile读与下面的普通写重排序volatile读之后StoreLoad禁止上面的volatile写与下面的volatile读/写重排序volatile写之后StoreLoad是开销最大的屏障因为它要求写缓冲区全部刷回主内存并等待其他CPU的缓存失效确认。这也是为什么volatile写比普通写慢的原因。4.3 一个容易忽略的细节volatile数组volatile修饰数组时只保证数组引用的可见性不保证数组元素的可见性。也就是说private volatile int[] arr new int[10];arr new int[20]这个引用赋值对其他线程可见但arr[0] 1这种元素修改不保证可见。要让元素也可见得用AtomicIntegerArray或者对每个元素单独用volatile不现实或者用锁。这个坑我在一个缓存刷新模块里踩过当时以为给数组加了volatile就万事大吉结果元素更新死活同步不过去排查了半天才反应过来。5. 什么时候该用volatile场景与反例5.1 状态标志位最典型的适用场景volatile最经典的用法就是状态标志位。比如一个后台线程需要根据外部信号优雅停止public class Worker implements Runnable { private volatile boolean stopped false; public void stop() { stopped true; } Override public void run() { while (!stopped) { // 执行任务 } // 清理资源 } }这种场景下只有一个线程写stopped多个线程读且写操作不依赖当前值不是stopped !stopped这种完美契合volatile的能力边界。5.2 一次性安全发布volatile可以用于安全发布对象。比如一个配置对象初始化后不再修改public class ConfigHolder { private volatile Config config; public Config getConfig() { if (config null) { config loadConfig(); } return config; } }如果多个线程可能同时初始化还是得配合synchronized做双重检查。但如果初始化只发生一次且由单个线程完成volatile就足够了。5.3 这些场景别用volatile计数器count这种复合操作volatile救不了用AtomicInteger。依赖当前值的判断if (flag) { flag false; }这种检查和修改之间可能被插入得用锁。多个变量之间的约束如果两个变量有不变式关系比如a b 100单独用volatile无法保证两个写操作的原子性。我见过一个项目里用volatile修饰一个Map然后多线程往里put结果数据丢失。volatile只保证引用可见put操作的线程安全得靠ConcurrentHashMap。6. 实测验证用代码证明volatile的效果6.1 复现可见性问题先跑一段不加volatile的代码确认问题真实存在public class NoVolatileDemo { private static boolean flag true; public static void main(String[] args) throws InterruptedException { new Thread(() - { int i 0; while (flag) { i; } System.out.println(循环结束i i); }).start(); Thread.sleep(2000); flag false; System.out.println(flag 已设置为 false); } }在多数JVM实现下这个程序会一直卡住worker线程不会打印“循环结束”。注意这不是100%必现取决于JIT编译器的优化行为。有时候跑几次才出现这也是这类Bug难排查的原因。6.2 加上volatile后验证把flag改成volatile再跑一次private static volatile boolean flag true;这次worker线程会在主线程设置flag false后很快退出循环。你可以多跑几次结果稳定。6.3 用JIT编译日志观察优化行为如果想更深入验证可以加JVM参数打印编译日志java -XX:PrintCompilation -XX:UnlockDiagnosticVMOptions -XX:PrintAssembly NoVolatileDemo你会看到worker线程的循环方法被JIT编译后flag的读取被提升到了循环外面循环不变量提升导致每次判断用的都是缓存值。加上volatile后这种优化被禁止每次循环都会重新读取。这个实验我建议每个学JMM的人都亲手做一遍比看十篇文章都管用。7. 面试与实战中的高频误区7.1 volatile能替代synchronized吗不能。这是面试里出现频率最高的问题之一。volatile只解决可见性和有序性不解决原子性。synchronized三者都解决但代价更高。选择哪个取决于场景如果只是状态标志位volatile足够如果涉及复合操作必须用锁或原子类。7.2 volatile变量一定从主内存读吗严格来说JMM不保证“一定从主内存读”它保证的是“读到的值是最新写入的”。硬件层面可能从缓存读但缓存一致性协议如MESI会保证缓存行失效效果上等价于读到最新值。理解这一点有助于避免过度纠结底层细节。7.3 单例模式里volatile是必须的吗如果用的是静态内部类或者枚举实现单例不需要volatile。只有双重检查锁定DCL模式下volatile才是必须的用来禁止new操作的重排序。很多人背了DCL的代码但说不清为什么加volatile面试时容易被追问到卡壳。7.4 volatile和AtomicInteger怎么选AtomicInteger底层用CAS实现保证原子性适合计数器场景。volatile适合单一写、多读的标志位。AtomicInteger的get()和set()方法本身也依赖volatile字段来保证可见性可以理解为volatile的增强版。8. 我踩过的坑与调试心得第一个坑是前面提到的volatile数组。当时做一个配置热更新功能用volatile修饰了一个配置数组以为改元素就能生效结果线上环境死活不刷新。后来改成每次替换整个数组引用才解决。教训是volatile管引用不管内容。第二个坑是在一个高并发统计模块里用volatile long做计数器压测时数据对不上。原因就是long在32位JVM上可能不是原子写加上volatile也不保证count的原子性。后来换成LongAdder性能和数据准确性都上来了。第三个坑比较隐蔽在一个双重检查锁定的缓存加载器里忘了给instance加volatile。单线程测试完全正常多线程压测时偶发NullPointerException。排查时用-XX:PrintAssembly看汇编才发现对象初始化被重排序了。加上volatile后问题消失。调试这类问题的通用思路是先确认是不是可见性问题加打印或加volatile试试再用jstack看线程状态必要时用PrintCompilation和PrintAssembly观察JIT优化。不要一上来就怀疑锁的问题可见性问题的表现往往更“安静”。提示如果你在排查多线程Bug时发现“加一行日志就好了”这几乎可以确诊是可见性或重排序问题。日志的IO操作会插入内存屏障意外地“修复”了问题但这不是真正的修复。9. 从volatile延伸出去的知识脉络volatile是理解JMM的一把钥匙。顺着它往下挖可以串联起内存屏障、happens-before、缓存一致性协议MESI、JIT优化策略、伪共享False Sharing等一系列知识点。比如Contended注解解决的伪共享问题本质上是缓存行层面的可见性和性能问题和volatile的底层机制一脉相承。再往上走volatile和final、synchronized、Atomic系列、VarHandleJava 9共同构成了Java并发编程的可见性工具箱。VarHandle提供了更细粒度的内存访问模式控制可以看作是volatile的进阶替代方案支持getAcquire、setRelease等更灵活的内存语义。如果你正在准备面试建议把volatile的可见性、有序性、不保证原子性这三点吃透再配合DCL单例、状态标志位两个场景基本能覆盖大部分追问。如果面试官继续深挖内存屏障和happens-before能说清楚StoreLoad屏障的作用和volatile写读的happens-before关系就已经超过大多数候选人了。最后分享一个我自己的学习习惯每学一个并发关键字就写一个能复现问题的最小Demo然后逐步加条件验证。volatile的Demo我前后改了七八版从最简单的死循环到带JIT日志的版本每改一次理解就深一层。这种“代码驱动”的学习方式比单纯看文档效率高得多。
1. 从一个诡异的死循环说起如果你写过Java多线程代码大概率遇到过这样一种情况程序逻辑看起来完全正确但线程就是卡在某个循环里出不来加一行打印语句它又正常了。这种“薛定谔的Bug”背后十有八九是内存可见性在作祟。这篇文章要聊的volatile关键字就是Java里解决可见性问题的第一把交椅。它不像synchronized那样能保证原子性也不像ReentrantLock那样功能丰富但它在特定场景下轻量、高效是并发编程里绕不开的基础设施。如果你正在学JMMJava内存模型、正在被面试官追问volatile和synchronized的区别、或者正在排查一个多线程环境下“改了值但另一个线程读不到”的诡异问题那这篇内容就是写给你的。我会从CPU缓存架构讲起把可见性问题的根因一层层剥开然后落到volatile的底层实现、使用场景、常见误区和实测验证上。中间会穿插大量我实际踩过的坑和调试经验尽量让你看完之后不仅知道“怎么用”更清楚“为什么必须这么用”。2. 可见性问题的根因CPU缓存与JMM的抽象2.1 一个不加volatile的经典翻车现场先看一段代码这段代码我最早是在一个后台任务调度模块里遇到的简化后大概长这样public class VisibilityDemo { private static boolean running true; public static void main(String[] args) throws InterruptedException { Thread worker new Thread(() - { while (running) { // 执行任务 } System.out.println(worker thread stopped); }); worker.start(); Thread.sleep(1000); running false; System.out.println(main thread set running false); } }直觉上主线程把running改成false之后worker线程应该马上跳出循环并打印“worker thread stopped”。但实际跑起来你会发现worker线程很可能永远卡在while循环里主线程那句打印倒是正常输出了。更诡异的是如果你在while循环里加一句System.out.println(running)程序就正常退出了。这不是玄学这是内存可见性问题在真实环境里的表现。2.2 从CPU缓存层级理解“为什么读不到”要搞清楚这个问题得先理解现代计算机的内存架构。CPU的执行速度远远快于主内存的读写速度为了弥补这个差距硬件层面引入了多级缓存层级典型容量访问延迟归属寄存器几十到几百字节约0.3ns单核私有L1 Cache32KB~64KB约1ns单核私有L2 Cache256KB~512KB约3~10ns单核私有L3 Cache数MB到数十MB约10~30ns多核共享主内存GB级别约60~100ns全局共享当worker线程第一次读取running变量时它会把值从主内存加载到自己的工作内存对应CPU缓存和寄存器的抽象。之后每次循环判断它可能直接从缓存里读而不是回主内存重新加载。主线程修改running false时写的是主内存或者主线程自己的缓存再刷回主内存但worker线程的缓存里还是旧的true于是死循环就出现了。这就是可见性问题的本质一个线程对共享变量的修改另一个线程不一定能立刻看到。2.3 JMM给出的抽象模型Java内存模型JMM把硬件的这套缓存机制抽象成了“主内存”和“工作内存”的概念。每个线程有自己的工作内存共享变量存在主内存里。线程对变量的所有操作都必须在工作内存中进行不能直接读写主内存。JMM定义了8种原子操作来规范主内存和工作内存之间的交互lock、unlock、read、load、use、assign、store、write。这套模型本身不保证一个线程的写操作何时对其他线程可见也不保证多线程执行的顺序。volatile、synchronized、final这些关键字本质上都是在JMM的规则框架下对可见性和有序性做出额外承诺。注意JMM是一个规范不是物理实现。不同JVM、不同CPU架构下的具体行为可能有差异但都必须满足JMM定义的语义。3. volatile到底做了什么可见性与有序性的双重承诺3.1 可见性保证的底层机制给running加上volatile之后程序就能正常退出了。这背后发生了什么从JMM层面看volatile变量的写操作会立刻刷回主内存读操作会直接从主内存加载。但这只是抽象描述真正的实现依赖CPU提供的内存屏障指令。以x86架构为例volatile写操作前面会插入一个StoreStore屏障后面插入一个StoreLoad屏障volatile读操作前面插入LoadLoad屏障后面插入LoadStore屏障。这些屏障指令的作用是禁止特定类型的指令重排序并强制将写缓冲区中的数据刷到缓存一致性协议能看到的层级。用生活化的类比普通变量像是你把文件存在自己电脑的桌面上别人看不到volatile变量像是你每次改完都立刻上传到共享网盘别人每次读都从网盘拉最新版本。代价是每次读写都要走网络比本地操作慢。3.2 有序性保证禁止指令重排序volatile的第二个承诺是禁止指令重排序。编译器和CPU为了优化性能会在不影响单线程语义的前提下调整指令执行顺序。但在多线程环境下这种重排序可能导致意想不到的结果。经典的例子是双重检查锁定DCL单例模式public class Singleton { private static volatile Singleton instance; public static Singleton getInstance() { if (instance null) { synchronized (Singleton.class) { if (instance null) { instance new Singleton(); } } } return instance; } }instance new Singleton()这行代码在字节码层面大致分三步分配内存、初始化对象、将引用指向内存地址。如果没有volatile步骤2和步骤3可能被重排序。另一个线程可能在instance已经非null但对象还没初始化完成时拿到引用使用时就会出问题。volatile通过插入内存屏障禁止了这种重排序。3.3 volatile不保证原子性这是最容易踩的坑。很多人以为volatile能替代synchronized实际上它只保证可见性和有序性不保证原子性。看下面这个例子public class Counter { private volatile int count 0; public void increment() { count; } }count看起来是一行代码实际上包含读取、加一、写回三个操作。多个线程同时执行时即使count是volatile的最终结果也可能小于预期。因为读取和写回之间可能被其他线程插入。要保证原子性得用synchronized、AtomicInteger或者LongAdder。volatile只适合“一写多读”或者“状态标志位”这类场景。4. 内存屏障与happens-beforevolatile的规则边界4.1 happens-before规则中的volatile条款JMM用happens-before关系来描述两个操作之间的可见性保证。如果操作A happens-before 操作B那么A的结果对B可见。volatile相关的规则有两条volatile写 happens-before 后续任意线程对该volatile变量的读。这意味着一个线程写了volatile变量后另一个线程读这个变量时能看到写之前的所有操作结果。volatile读 happens-before 后续对该volatile变量的写。这条相对少用但理解它有助于把握完整的语义。这两条规则组合起来让volatile变量成了一个“同步点”。写线程在写volatile之前的所有操作对读线程在读volatile之后的所有操作都可见。4.2 四种内存屏障的实际作用JMM定义了四种内存屏障volatile的读写会插入不同的屏障组合屏障类型作用插入位置LoadLoad禁止上面的普通读与下面的volatile读重排序volatile读之后StoreStore禁止上面的普通写与下面的volatile写重排序volatile写之前LoadStore禁止上面的volatile读与下面的普通写重排序volatile读之后StoreLoad禁止上面的volatile写与下面的volatile读/写重排序volatile写之后StoreLoad是开销最大的屏障因为它要求写缓冲区全部刷回主内存并等待其他CPU的缓存失效确认。这也是为什么volatile写比普通写慢的原因。4.3 一个容易忽略的细节volatile数组volatile修饰数组时只保证数组引用的可见性不保证数组元素的可见性。也就是说private volatile int[] arr new int[10];arr new int[20]这个引用赋值对其他线程可见但arr[0] 1这种元素修改不保证可见。要让元素也可见得用AtomicIntegerArray或者对每个元素单独用volatile不现实或者用锁。这个坑我在一个缓存刷新模块里踩过当时以为给数组加了volatile就万事大吉结果元素更新死活同步不过去排查了半天才反应过来。5. 什么时候该用volatile场景与反例5.1 状态标志位最典型的适用场景volatile最经典的用法就是状态标志位。比如一个后台线程需要根据外部信号优雅停止public class Worker implements Runnable { private volatile boolean stopped false; public void stop() { stopped true; } Override public void run() { while (!stopped) { // 执行任务 } // 清理资源 } }这种场景下只有一个线程写stopped多个线程读且写操作不依赖当前值不是stopped !stopped这种完美契合volatile的能力边界。5.2 一次性安全发布volatile可以用于安全发布对象。比如一个配置对象初始化后不再修改public class ConfigHolder { private volatile Config config; public Config getConfig() { if (config null) { config loadConfig(); } return config; } }如果多个线程可能同时初始化还是得配合synchronized做双重检查。但如果初始化只发生一次且由单个线程完成volatile就足够了。5.3 这些场景别用volatile计数器count这种复合操作volatile救不了用AtomicInteger。依赖当前值的判断if (flag) { flag false; }这种检查和修改之间可能被插入得用锁。多个变量之间的约束如果两个变量有不变式关系比如a b 100单独用volatile无法保证两个写操作的原子性。我见过一个项目里用volatile修饰一个Map然后多线程往里put结果数据丢失。volatile只保证引用可见put操作的线程安全得靠ConcurrentHashMap。6. 实测验证用代码证明volatile的效果6.1 复现可见性问题先跑一段不加volatile的代码确认问题真实存在public class NoVolatileDemo { private static boolean flag true; public static void main(String[] args) throws InterruptedException { new Thread(() - { int i 0; while (flag) { i; } System.out.println(循环结束i i); }).start(); Thread.sleep(2000); flag false; System.out.println(flag 已设置为 false); } }在多数JVM实现下这个程序会一直卡住worker线程不会打印“循环结束”。注意这不是100%必现取决于JIT编译器的优化行为。有时候跑几次才出现这也是这类Bug难排查的原因。6.2 加上volatile后验证把flag改成volatile再跑一次private static volatile boolean flag true;这次worker线程会在主线程设置flag false后很快退出循环。你可以多跑几次结果稳定。6.3 用JIT编译日志观察优化行为如果想更深入验证可以加JVM参数打印编译日志java -XX:PrintCompilation -XX:UnlockDiagnosticVMOptions -XX:PrintAssembly NoVolatileDemo你会看到worker线程的循环方法被JIT编译后flag的读取被提升到了循环外面循环不变量提升导致每次判断用的都是缓存值。加上volatile后这种优化被禁止每次循环都会重新读取。这个实验我建议每个学JMM的人都亲手做一遍比看十篇文章都管用。7. 面试与实战中的高频误区7.1 volatile能替代synchronized吗不能。这是面试里出现频率最高的问题之一。volatile只解决可见性和有序性不解决原子性。synchronized三者都解决但代价更高。选择哪个取决于场景如果只是状态标志位volatile足够如果涉及复合操作必须用锁或原子类。7.2 volatile变量一定从主内存读吗严格来说JMM不保证“一定从主内存读”它保证的是“读到的值是最新写入的”。硬件层面可能从缓存读但缓存一致性协议如MESI会保证缓存行失效效果上等价于读到最新值。理解这一点有助于避免过度纠结底层细节。7.3 单例模式里volatile是必须的吗如果用的是静态内部类或者枚举实现单例不需要volatile。只有双重检查锁定DCL模式下volatile才是必须的用来禁止new操作的重排序。很多人背了DCL的代码但说不清为什么加volatile面试时容易被追问到卡壳。7.4 volatile和AtomicInteger怎么选AtomicInteger底层用CAS实现保证原子性适合计数器场景。volatile适合单一写、多读的标志位。AtomicInteger的get()和set()方法本身也依赖volatile字段来保证可见性可以理解为volatile的增强版。8. 我踩过的坑与调试心得第一个坑是前面提到的volatile数组。当时做一个配置热更新功能用volatile修饰了一个配置数组以为改元素就能生效结果线上环境死活不刷新。后来改成每次替换整个数组引用才解决。教训是volatile管引用不管内容。第二个坑是在一个高并发统计模块里用volatile long做计数器压测时数据对不上。原因就是long在32位JVM上可能不是原子写加上volatile也不保证count的原子性。后来换成LongAdder性能和数据准确性都上来了。第三个坑比较隐蔽在一个双重检查锁定的缓存加载器里忘了给instance加volatile。单线程测试完全正常多线程压测时偶发NullPointerException。排查时用-XX:PrintAssembly看汇编才发现对象初始化被重排序了。加上volatile后问题消失。调试这类问题的通用思路是先确认是不是可见性问题加打印或加volatile试试再用jstack看线程状态必要时用PrintCompilation和PrintAssembly观察JIT优化。不要一上来就怀疑锁的问题可见性问题的表现往往更“安静”。提示如果你在排查多线程Bug时发现“加一行日志就好了”这几乎可以确诊是可见性或重排序问题。日志的IO操作会插入内存屏障意外地“修复”了问题但这不是真正的修复。9. 从volatile延伸出去的知识脉络volatile是理解JMM的一把钥匙。顺着它往下挖可以串联起内存屏障、happens-before、缓存一致性协议MESI、JIT优化策略、伪共享False Sharing等一系列知识点。比如Contended注解解决的伪共享问题本质上是缓存行层面的可见性和性能问题和volatile的底层机制一脉相承。再往上走volatile和final、synchronized、Atomic系列、VarHandleJava 9共同构成了Java并发编程的可见性工具箱。VarHandle提供了更细粒度的内存访问模式控制可以看作是volatile的进阶替代方案支持getAcquire、setRelease等更灵活的内存语义。如果你正在准备面试建议把volatile的可见性、有序性、不保证原子性这三点吃透再配合DCL单例、状态标志位两个场景基本能覆盖大部分追问。如果面试官继续深挖内存屏障和happens-before能说清楚StoreLoad屏障的作用和volatile写读的happens-before关系就已经超过大多数候选人了。最后分享一个我自己的学习习惯每学一个并发关键字就写一个能复现问题的最小Demo然后逐步加条件验证。volatile的Demo我前后改了七八版从最简单的死循环到带JIT日志的版本每改一次理解就深一层。这种“代码驱动”的学习方式比单纯看文档效率高得多。
