有些Java并发问题表面上看是代码写法不对根子上其实是对JMMJava内存模型理解不到位。JMM不是一个抽象的理论摆设它直接决定了你写的volatile、synchronized、final在多线程环境下到底怎么工作也决定了数据什么时候可见、指令能不能重排、死锁和诡异数据不一致问题到底从哪来。我这些年排查过不少线上并发问题最后都绕回到JMM的几个核心规则上。这篇文章就把JMM从设计思路到实际落地完整拆一遍适合已经写过并发代码、想深入理解底层机制的开发者也适合准备面试想要系统梳理的人。1. 整体设计思路JMM到底在解决什么问题1.1 并发编程的三大顽疾从何而来并发编程谈来谈去核心就三个问题可见性、原子性、有序性。这三个问题不是Java特有的而是计算机体系结构带来的天然限制。CPU为了提速搞了多级缓存编译器为了优化搞了指令重排线程库为了调度搞了时间片切换。每一个优化在单线程下都无所谓但一旦多线程共享数据这些优化就会捅出篓子。可见性问题最典型的场景一个线程改了共享变量另一个线程读到的还是旧值。这不是玄学是CPU缓存搞的鬼。线程A改了变量的值这个新值可能还躺在CPU的L1缓存里没来得及写回主内存线程B读的时候从自己的缓存里拿自然读到的是旧值。你可能会说那我把缓存关了不就行了实际上不行因为缓存带来的性能提升太可观了现代CPU宁可给你留一堆内存屏障指令让你自己协调也不愿意放弃缓存。原子性问题更直白i这行代码在字节码层面是四条指令读取、计算、写回、更新。线程A执行到一半线程B插进来两个线程都在旧值上加1最终结果就丢了更新。这类问题靠JMM本身解决不了得靠锁或者原子类。有序性问题最阴编译器为了指令流水线效率会把没有数据依赖的指令交换顺序。单线程下交换顺序没问题因为结果一致。但多线程下另一个线程看到的执行顺序可能和你代码写的不一样。最经典的例子就是双重检查锁里的那个半初始化对象后面会详细讲。1.2 JMM的设计目标与核心模型JMM没有试图去消灭这三个问题因为消灭的代价太大而是定义了一套规则让你在写代码的时候有据可循同时又不至于让所有优化失效。这就是JMM最精妙的地方它提供了一系列happens-before规则只要你的代码满足这些规则JVM就保证可见性和有序性如果不满足那一切后果自负。JMM的核心模型是主内存和工作内存。主内存是全局共享的所有变量都在这每个线程还有自己的工作内存是变量副本的私有缓存区。线程对变量的所有操作都必须先在工作内存中进行不能直接读写主内存。工作内存和主内存之间通过特定的交互协议同步数据JMM定义了load、store、read、write、use、assign、lock、unlock这八种操作来规范同步过程。这里有个容易混淆的点Java里的内存不完全等于物理内存。JMM描述的是一个抽象的内存模型它对应到真实的硬件架构上主内存可能是物理RAM工作内存可能落在CPU缓存甚至寄存器里。所以你在理解的时候别把它往物理内存上死套它只是一套逻辑模型。1.3 为什么说JMM是编译器和CPU优化下的安全边界JMM的价值在于它让你不需要深入了解每一种CPU架构底层的缓存一致性协议细节只需要遵守JMM定义的规则就能写出在所有平台上行为一致的并发代码。JVM在被要求保证某些语义时会在关键位置插入内存屏障指令这些屏障会告诉CPU这条屏障之前的指令执行结果必须对屏障之后的指令可见或者某些重排必须被禁止。这个设计理念类似交通规则你不一定需要知道每个路口的信号灯是怎么联动的只需要知道红灯停绿灯行就能安全通行。JMM就是Java并发编程的交通规则它给你划定了安全边界。边界内你可以放心使用各种高级并发工具边界外行为依赖具体平台写出来的代码就像在悬崖边开车。2. 核心机制详解happens-before规则与三大特性2.1 happens-before规则的深层意义happens-before是JMM里最重要的概念之一它定义了两个操作之间的偏序关系。如果操作A happens-before操作B那么A的执行结果对B是可见的且A的执行顺序在B之前。这套规则的好处是它不依赖于你实际用了什么同步机制只要存在happens-before关系JVM就必须保证对应的内存可见性和有序性。JMM规定了六条天然的happens-before规则程序顺序规则同一个线程中写在前面的代码对后面的代码可见。监视器锁规则一个锁的unlock操作happens-before于后续对这个锁的lock操作。volatile规则对一个volatile变量的写操作happens-before于后续对这个变量的读操作。传递性如果A happens-before BB happens-before C那么A happens-before C。线程启动规则Thread.start()调用happens-before于该线程内的所有操作。线程终止规则线程内的所有操作happens-before于检测到该线程终止。这六条规则看起来简单但组合起来威力巨大。比如传递性配合volatile规则就能解决我在实际项目中遇到的一个很典型的问题一个线程发布配置对象另一个线程读取配置。只要保证配置对象的所有字段都是final的且对象引用的写入是volatile的那读取线程拿到新引用后对象的字段一定是初始化完成的不会看到半初始化状态。2.2 可见性从CPU缓存到volatile可见性问题我前面提到过这里展开说volatile的底层实现。当你给一个变量加上volatile修饰后JVM在编译时会做两件事一是对被修饰的变量加上内存屏障防止它前面的读写操作被重排到它后面也防止后面的操作被排到它前面二是对volatile变量的写操作会强制刷新到主内存读操作会强制从主内存加载不走工作内存。但有一点很多人会搞错volatile保证可见性和有序性不保证原子性。所以volatile int count然后多个线程执行count结果依然是错的。我看到过不少生产事故就是从这里来的开发以为是volatile问题其实是原子性问题。解决方案是用AtomicInteger或者加锁。如果你需要的是一个复合操作的原子性volatile帮不了你。2.3 原子性锁与CAS的取舍原子性的本质是不可分割。JMM层面提供了lock和unlock操作对应到Java语法就是synchronized关键字和Lock接口。进入synchronized块时执行lock退出时执行unlock这两个操作之间的代码就是原子的。底层依赖操作系统的互斥量mutex也是重量级操作。好在现代JDK对synchronized做了大量优化偏向锁、轻量级锁、自旋锁让它在大多数场景下性能不差。我的一个实操建议如果你的临界区代码很短比如就是给一个计数器加1优先考虑CASCompare And Swap。JDK的Unsafe类提供了原子操作AtomicInteger等类就构建在这之上。CAS的好处是没有上下文切换失败就重试在低竞争场景下比锁快好几倍。但高竞争下CAS的自旋会白白消耗CPU这时候反而用锁更合适。我的经验是可以把锁设计成分段的比如LongAdder的思路把热点打散到多个单元上。2.4 有序性指令重排的约束机制指令重排是编译器、处理器为了性能做的事。JMM通过内存屏障来约束重排。内存屏障分四种LoadLoad、StoreStore、LoadStore、StoreLoad。各有各的用途。volatile写会在前面插入StoreStore屏障防止之前的普通写被重排到volatile写之后volatile写在后面插入StoreLoad屏障防止volatile写被重排到之后的普通读、写之前。volatile读会在后面插入LoadLoad和LoadStore屏障防止后面的普通读和写被重排到volatile读之前。实际排查有序性问题时你会发现它比可见性更隐蔽。可见性问题好歹能看到两个线程读到的值不一致有序性问题直接让代码逻辑在执行顺序上和你预期不一致表现出来就是概率性的、极难复现的bug。我处理过一个经典案例后面第三节会用代码展示。3. 从理论到落地volatile、synchronized与final的正确姿势3.1 volatile适用场景与不适用场景volatile适合几个场景状态标记、一次性安全发布、独立观察变量。状态标记很常见一个线程跑循环另一个线程把标记位改成false让它停。这里volatile足够因为写标记位是原子操作只需要保证可见性。一次性安全发布说的是你有一个不可变对象用volatile引用它。因为不可变对象的字段是final的通过volatile发布后读线程能保证看到完全初始化的对象。这个模式在我维护的一个配置中心里用过配置对象就是全final字段配置更新时整体替换引用。不适用场景也很明确复合操作、多线程写同一个变量。比如计数器累加、状态机转换、读改写操作这些要么用锁要么用原子类。有人会问多个线程写volatile变量不是也能保证可见性吗能但保证不了计算正确因为计算包含多个步骤volatile管不着步骤间的串行性。3.2 synchronized的锁升级机制与内存语义synchronized从JDK 1.6开始做了大改造。无锁状态 → 偏向锁 → 轻量级锁 → 重量级锁这条路走完。偏向锁解决的是单个线程反复进入同步块的开销JVM会把这个锁标记为偏向该线程之后该线程再进入不需要任何同步操作。一旦有其他线程来竞争偏向锁就撤销升级为轻量级锁。轻量级锁通过CAS把锁对象的Mark Word替换为线程栈中的锁记录失败就升级为重量级锁。这些锁的底层其实也是内存屏障。synchronized的lock操作相当于在进入临界区前插入LoadLoad和LoadStore屏障unlock操作相当于在退出临界区后插入StoreStore和StoreLoad屏障。这也解释了为什么synchronized能保证锁内代码对后续获取同一把锁的线程可见——因为锁的释放涉及了内存屏障把修改刷到了主内存锁的获取又涉及屏障把主内存的最新值加载回来。关于synchronized和ReentrantLock的选择我的建议能用synchronized尽量用synchronized因为它在JDK层面不断优化性能已经和Lock平起平坐。只有在需要可中断、超时、公平锁、多个条件变量时再考虑ReentrantLock。前者是语法层面后者是API层面前者写起来更不容易出错。3.3 final的内存语义为什么不可变对象是并发利器final的内存语义和volatile有相似之处final字段的写操作在构造器中完成之后对final字段的读操作不会再看到初始值即不会看到默认零值。这个保证很重要它让不可变对象不需要额外同步就能安全发布。原理是JMM对final有特殊处理在构造器结束前JMM会插入一个StoreStore屏障保证final字段的写操作不会重排到构造器之外。而final字段的读操作会被编译器视为可能来自另一个线程会自动避免重排到写操作之前。实际开发中我几乎把所有没有可变需求的对象都设计成了全final字段。这样不光代码更清晰还天然免除了并发修改风险。这比什么高深的锁技巧都管用不要通过锁去保护可变数据而是直接设计出不可变数据从根源上消灭竞争条件。这条经验后来帮团队减少了很多潜在的并发bug。3.4 经典案例分析双重检查锁为何需要volatile双重检查锁DCL是面试常见题也是真实事故高发点。不完整的写法是这样的public class Singleton { private static Singleton instance; public static Singleton getInstance() { if (instance null) { synchronized (Singleton.class) { if (instance null) { instance new Singleton(); } } } return instance; } }这段代码在JMM下是有问题的。instance new Singleton()在字节码层面是三步分配内存、调用构造器初始化、将引用赋值给instance。问题在于第三步和第二步之间可能被重排。如果重排先执行第三步再执行第二步另一个线程就会在instance不是null的情况下访问到一个尚未初始化完成的对象。解决办法就是给instance加上volatile。volatile写会插入StoreStore屏障禁止了初始化和发布引用之间的重排。有了volatileinstance引用被其他线程看到时构造器里的初始化一定已经完成了。这是volatile有序性保证的经典应用也是面试官最喜欢深挖的细节。4. 实操经验从线上故障中学到的JMM排查方法论4.1 一次诡异的配置读取丢失事件之前有个线上服务配置模块用一个HashMap存配置项偶尔会出现服务读不到刚更新的配置。当时开发怀疑是HashMap线程不安全导致的但换成了ConcurrentHashMap后问题还是偶发。后来我们仔细查了代码发现问题的核心在发布端和读取端用了不同的同步机制发布端用了synchronized锁读取端直接读两者之间没有happens-before关系。这个故障给了我两个教训。第一共享数据的发布和读取必须配对使用同一套同步机制否则就是说好了用锁但没锁全JMM完全不保证任何可见性。第二遇到偶发问题不要只看数据结构线程安不安全要先画一遍代码路径标注出每条路径上的happens-before关系看看关键数据是否在每条路径上都被正确同步。这套方法论后来成了我排查并发问题的基础动作。4.2 JMM视角下的线程安全判定三步法我在给团队做代码评审时经常用三步法来判定一段并发代码是否安全。先把所有被多个线程访问的共享变量列出来然后对每个变量找到所有读和写的发生点最后沿着执行路径检查是否每一条读写路径都存在happens-before关系。只要有一个变量在任意一条路径上缺失同步这段代码就不是线程安全的。这个三步法看着简单实际操作中能揪出许多隐藏问题。尤其要注意写到日志里的数据、发到消息队列的数据、放到ThreadLocal里的数据也都是共享的因为它们会被其他线程读取。很多人只盯着显式的共享变量忽略了隐式共享这是线程安全bug最常见的根源。所谓的隐式共享就是你不自觉地把数据从线程A传到了线程B。例如把对象的非volatile字段当作参数传给新线程。这种时候如果传递路径上没有happens-before关系新线程看到的数据可能是老的。解决方法是发布前加一次volatile写或者干脆用线程启动规则。我之前就因为一个线程池submit传过去的老参数跑出来的结果和预期不一致排查了很久才发现这里少了同步。4.3 用JMM基础知识快速定位死循环和脏读死循环和脏读这两个问题从JMM角度看是两种典型失效。死循环场景主线程把标记位设为false工作线程还在while循环里转因为工作线程在自己的工作内存里缓存了标记位的旧值永远看不到主线程的修改。解法就是标记位用volatile修饰。脏读场景读线程读到一个对象的部分字段是新的、部分字段是旧的。看代码以为是一个原子更新实际上对象不是不可变的字段也是散着写的JMM对这些普通字段的可见性不做任何保证。解法是让对象不可变或者整体加锁发布。排查这些问题的顺序我建议是先确认有没有共享可变数据再确认有没有正确同步最后确认有没有锁泄漏或者死锁。多数时候是前两步出问题JMM规则没吃透。理解JMM底层原理不是让你成为面试表演家而是让你在线上问题面前能快速定性不瞎猜。一个能准确区分可见性bug、原子性bug、有序性bug的人排查并发问题的速度比试错法快一个量级。4.4 关于JMM的几条避坑心得我在实际踩过几次坑后总结出几条常规文档里不太会写的判断依据。凡是多线程访问普通字段且不通过synchronized、Lock、volatile、原子类这些手段基本等于裸奔出事只是概率问题。凡是看到懒加载的单例第一反应就该检查双重检查锁有没有加volatile因为这是最容易被忽视的一个位置。凡是看到先写配置到Map再发个消息通知别人读这种模式就得立刻警觉通知本身可能带有同步语义但Map里的数据不是volatile的消息通了不代表数据可见。还有一条细节很多人不清楚String的不可变性不代表指向它的引用是线程安全的。你有一个static的String字段多个线程直接赋值那这个引用本身还是需要volatile或锁保护。不可变对象保证的是对象内容无法修改但引用替换是另一个层面的事。关于长字段long、double在JMM里有一个历史包袱对于64位的long和doubleJMM规范允许JVM把一次写入拆成两个32位的写入。因此在不同步的情况下读到的可能是高32位和低32位来自两次不同写入的拼接值。不过现代64位JVM通过底层对齐和原子写基本规避了这个问题但严格按JMM规范依然建议用volatile修饰共享的long或double至少能保证原子性。5. 辅助工具JMM内部原理的可视化验证与排查5.1 从字节码和汇编层面看内存屏障理解JMM只看规范容易云里雾里。我建议你把经过JIT编译后的汇编代码翻出来看那里面会有实际插入的内存屏障指令。JDK自带一个hsdis插件配合-XX:PrintAssembly参数能看到volatile写和synchronized enter/exit前后的lock前缀指令。lock前缀指令在x86平台上实际上就是用来实现内存屏障的。不过说实话大多数业务开发没必要看到汇编层面知道有这么回事就行。我更推荐在排查问题时写一个简单的单元测试用多个线程疯狂读写共享变量看看什么样子的代码稳定出问题、什么样子的代码不出问题。这种实证训练比死记规则有效得多。5.2 用代码复现可见性问题的实验模板想亲眼看看可见性问题可以构造一个最简单的实验。起一个线程循环读取一个共享boolean变量主线程改这个变量的值。不加volatile时实验大概率会停不下来。加上volatile后程序很快退出。这个实验建议你亲手跑一次跑完你对volatile的可见性保证会有刻骨铭心的理解。public class VisibilityDemo { private static boolean flag false; public static void main(String[] args) throws Exception { Thread t new Thread(() - { while (!flag) { // 空转 } System.out.println(exit); }); t.start(); Thread.sleep(100); flag true; } }注意运行模式。为了复现最好用Server模式跑也就是默认就是。因为client模式的JVM编译器优化程度不同可能没那么容易出问题。实际跑的时候你可以对比加volatile和不加volatile的区别以及把sleep去掉之后的区别。5.3 排查并发问题的工具链组合实际项目里建议组合使用几类工具。代码层面可以用FindBugs或者SpotBugs做静态扫描它能发现一部分synchronized使用不当和volatile缺失的模式。运行层面配合JDK自带的jvisualvm或者jconsole观察线程状态和锁等待。高并发压测时用GCeasy分析GC日志因为诡异的数据问题有时候是你以为的并发bug实际上是对GC停顿导致活锁或者缓存失效产生的间歇性不可用。还有一个容易被忽略的点JMM语义是说代码在正确同步的前提下行为才能被保证但真实系统里缓存一致性协议如MESI是一个独立的硬件机制它在某些场景下能额外保证可见性导致你不加volatile也能跑对这反而会麻痹你。测试环境偶发跑对大风大浪压测时问题才集中爆发。所以不要把我测了没问题当成我的代码符合JMM的证据要以规则为准而不是以运气为准。6. 经典问题实录与速查我在面试、带新人、排查问题的过程中遇到最多的JMM相关疑问就是那几个高频点整理成一张速查表放在这里。问题原因正确解法易错点多线程i丢失更新复合操作非原子AtomicInteger或synchronized误以为volatile能解决while循环读标记位不退可见性缺失标记位加volatile忘了写屏障和读屏障的效果双重检查锁拿到半初始化对象指令重排instance加volatile漏加volatile但测试不出问题构造函数逸出未初始化对象被发布构造器中不发布this怎么复查都难发现读对象部分字段新部分旧字段分散写入不可见不可变对象或整体发布过度依赖不可变对象的部分不可变性这里特别解释一下构造函数逸出。在构造器内部如果把this引用发布出去比如注册监听器或启动线程JMM不保证这个对象在构造完成前不被其他线程看到。这是个很隐蔽的坑因为代码看起来在构造器中做的事逻辑上应该是先完成再发布的。处理方式很简单不要在构造器里发布this如果确实需要发布用工厂方法创建对象后再发布。另一个高频问题是关于为什么int本身是原子的还要加volatile。int的读写确实原子但原子和可见是两个维度。即使int读写不撕裂工作内存里的副本依然可能滞后于主内存。所以共享int还是要volatile或锁来保证可见性。这个区分讲清楚后很多人对JMM的困惑会瞬间解开。最后补充一个容易被误解的点synchronized释放锁后会把当前线程工作内存中的变量刷新到主内存但这不是说进入synchronized就会主动去主内存把所有变量读一遍而是锁的获取会让后续读操作在主内存上看到最新的值。这两种微观机制的差别在实际性能调优时会影响你判断瓶颈在锁竞争还是在内存流量。7. JMM与Java并发工具之间的层次关系很多人在学JMM时会有个迷惑我明明用的是ConcurrentHashMap、CountDownLatch、Semaphore这些工具类底层也没有直接用volatile和synchronized怎么它们就是线程安全的答案在于这些工具类的内部实现。ConcurrentHashMap的节点数组是volatile的对桶位头节点做CAS操作时用到了Unsafe的原子操作 CountDownLatch的计数器本质上是基于AQSAbstractQueuedSynchronizer的同步状态AQS里的state字段是volatile的同时配套CAS来更新。锁、信号量、栅栏底层都围绕AQSAQS又依赖volatile的可见性和CAS的原子性。所以JMM是这一整套并发大厦的地基。你不需要每次都用最底层的volatile和synchronized手写并发控制但你必须知道工具类为什么安全、在什么边界内安全。比如ConcurrentHashMap保证的是单个操作线程安全但如果你要先检查再插入这种复合操作依然需要额外同步因为它提供的不是把所有操作绑成一个原子事务的强一致性。这个边界一旦模糊再高级的组件也会被用坏。从这个角度看理解JMM不只是为了应付面试更是为了培养一种并发安全意识知道什么是安全的什么是脆弱的哪一层在做保障哪一层需要自己兜底。我在评审代码时经常通过开发者对JMM的态度判断他写的并发代码靠不靠谱——一个真正理解JMM的人不会写出应该没事吧的代码。在实际项目中我对团队的要求是所有共享可变数据的访问必须能写清楚是哪一种同步机制在保护写不清楚就需要停下来思考。这份要求并不是为了形式主义而是因为并发bug的排查成本极高而JMM从规范层面帮助你提前识别风险。只要把规则吃透把习惯养好很多线上故障根本不会发生。这大概就是JMM最值得花时间的地方它不是一套冷冰冰的规范文档而是Java并发世界里的底层语法。你看懂了它世界就变得有序了。