在并发编程这块待久了你会发现真正让人头疼的不是死锁也不是线程池参数而是一些看起来“明明没问题”的代码跑起来却像中了邪一样随机出错。我印象最深的一次是在排查一个库存扣减的偶发超卖问题业务逻辑加了对账、落了日志、上了事务但在压力测试下就是会有几条数据不合预期。最后定位下来问题恰恰出在一个普通布尔字段的读写上——多个线程对同一个标志位的修改压根没有在第一时间同步到其他线程的“眼睛”里。这背后牵扯的就是Java并发中必须吃透的两件事线程安全与内存可见性。这篇文章不会堆概念而是从一次真实的排障现场出发把Java内存模型JMM、volatile、synchronized、原子类这些关键字逐个摆到台面上用可运行的代码案例告诉你为什么会有可见性问题怎么复现它又该怎么修。同时会把我在实际项目中踩过的一些坑、用过的排查工具和一些“看起来写了等于没写”的坑爹写法都一并分享出来。无论你是刚接触多线程的初学者还是已经写过一段时间并发代码的开发者相信看完都会有收获。1. 先从三个并发问题的根源说起1.1 原子性、可见性、有序性到底是什么很多人把线程安全等同于“加了锁就安全”这话只说对了一半。并发场景下的Bug通常逃不出三个维度原子性、可见性、有序性。原子性解决的是“操作不被中断”的问题。比如count这行代码看起来是一条语句底层其实是“读取-修改-写入”三步多线程同时执行时就会互相穿插把中间结果搞丢。可见性解决的是“一个线程改了另一个线程能不能立刻看到”的问题。有序性解决的是“代码执行顺序和指令顺序是否一致”的问题编译器、CPU都可能为了优化而重排序。这三个维度经常被混为一谈导致很多人用错了手段。比如你给一个布尔标志位加了synchronized本意是想保证可见性这当然有效但代价偏大又比如你用AtomicInteger保证了原子性却没注意被它引用的其他普通字段的可见性结果还是会翻车。所以排查并发问题时先要问自己一句这个Bug到底是哪个维度出的问题方向错了后面的修法肯定也错。1.2 CPU缓存与Java线程的“隔空喊话”要理解可见性先得知道数据在硬件上是怎么流转的。现代CPU无论多少核运算速度都快得离谱但内存却相对慢得多。为了平衡速度差CPU里加了多层缓存L1、L2、L3。每个核心各自持有部分缓存同时又共享最后一级缓存和主内存。线程运行在CPU核心上读变量时不一定直接去主内存拿而是优先读本核心的缓存写变量时也不一定立刻刷回主内存而是先落在缓存里等到某个时机再同步。这就带来了一个天然的问题核心A改了变量的值核心B如果还扎在自己的缓存里读旧值两边看到的数据就不一致。Java线程模型在设计时参考了这套硬件结构给出了自己的抽象每条线程有自己的“工作内存”共享变量存放在“主内存”。工作内存对应CPU缓存或寄存器主内存对应物理内存。具体什么时候刷新、什么时候失效JVM规范没有强制要求在每条指令上保证而是定义了一套规则——这就是Java内存模型的核心作用。所以“线程A写了一个变量线程B马上就能看到”在Java里从来都不是默认行为需要开发者在代码层面主动去建立联系。2. 用代码复现一个经典的可见性陷阱2.1 一个可能“永远停不下来”的循环纸上谈兵没意思直接来个现场实验。下面这段代码很有代表性public class VisibilityDemo { private static boolean flag true; public static void main(String[] args) throws InterruptedException { Thread worker new Thread(() - { long count 0; while (flag) { count; } System.out.println(线程退出共执行了 count 次循环); }); worker.start(); Thread.sleep(1000); flag false; System.out.println(主线程已将flag置为false); } }逻辑上主线程睡1秒后把flag改成falseworker线程应该很快跳出循环并打印退出信息。但你在你的电脑上跑一下大概率看到的情况是主线程打印完了worker线程却一直不打印退出消息程序卡在那里不退出。为什么会这样因为worker线程的循环体里每次循环都会去读flag。第一次读的时候发现是true于是进入循环进入循环后JIT编译器会做一个优化把flag的读取“提升”到循环外相当于循环变成了if (flag) { while(true) count; }——flag只读了一次之后不管主线程改不改worker线程都看不见。这种优化在单线程环境下完全没有问题因为单线程里flag在循环中确实没被修改。但到了多线程环境中它直接打破了可见性的预期。你可能会说“我的循环体里有别的操作比如打印日志会不会就不会被提升了”不一定。JIT优化极其细致它会分析循环体里哪些操作有副作用、哪些可以挪动。更靠谱的做法是显式地把线程间的共享关系声明清楚。2.2 为什么加了打印偶尔就“正常”了这个问题我回答过很多次也经常被追问“我给循环体里加一行System.out.println(count)程序就能正常退出是不是说明问题消失了”不问题还在。加打印后正常退出的原因通常是System.out内部是synchronized的println执行时经过了锁和内存屏障顺带触发了工作内存和主内存的同步这个效应“捎带”着把flag的新值刷新到了worker线程的可见范围。但这是副作用不是保证。你换个平台、换个JVM参数、换个时机行为可能又不一样。用副作用去“碰巧”解决并发问题是开发的大忌今天能跑不代表明天能跑。想彻底解决最直接的方案是把flag声明为volatile。volatile保证了对该变量的写操作立即刷新到主内存读操作则直接从主内存读同时禁止编译器和CPU对它做重排序。改完之后worker线程就能及时感知到变化并退出循环。这个关键字就是为这类“状态标志位”的场景设计的轻量、无锁性能代价远小于synchronized。private static volatile boolean flag true;后面我们在第5节会具体展开volatile的语义细节包括它什么时候能用、什么时候不能用。这里先记住一个结论多个线程共享一个状态标志来控制流程时优先考虑volatile。3. Java内存模型与happens-before规则3.1 JMM不只是规范更是排查问题的“标尺”很多人觉得JMM就是教科书上的一段概念工作中用不上。实际上我后来在团队里做代码审查时都是直接拿JMM的规则去对照一眼就能看出某个字段该不该加volatile、某个线程间协作能不能成立。Java内存模型规定所有共享变量存储在主内存每条线程有自己的工作内存。线程对共享变量的所有操作都必须在工作内存中进行不能直接读写主内存。不同线程之间无法直接访问对方的工作内存只能通过主内存来传递数据。这套模型意味着只要两个线程之间没有建立某种“协调规则”那么一个线程对变量的修改对另一个线程来说就是不可预知的。那“协调规则”在Java里具体长什么样就是happens-before关系。如果操作A happens-before操作B那么A的执行结果对B是可见的。JMM里总结了若干条规则程序次序规则、监视器锁规则、volatile变量规则、传递性、Thread.start()规则、Thread.join()规则等。拿监视器锁规则来说同一个锁上解锁操作happens-before后续的加锁操作。意思是线程A释放锁之前对共享变量做的所有修改线程B获取到同一把锁之后一定能看见。这就是为什么synchronized不仅能保证原子性也能保证可见性——它不是玄学而是有明确规则背书。用的时候心里要有数别只把它当“互斥工具”使。3.2 把happens-before关系画在脑子里我在实际分析并发问题时习惯把参与协作的线程和操作画成一条时间线然后逐条套happens-before规则。最常用的三条是对volatile变量的写操作happens-before后续对同一个volatile变量的读操作。对synchronized锁的解锁操作happens-before后续对同一个锁的加锁操作。Thread.start()的调用happens-before被启动线程中的任何操作被启动线程中的所有操作happens-beforeThread.join()返回。这三条记住了大部分可见性问题都能定位。比如前面那个循环案例主线程写flagworker线程读flag两者之间没有任何happens-before关系因此主线程的写入不保证对worker线程可见。声明成volatile后写flag和读flag之间就建立了happens-before关系问题迎刃而解。有一个常见的误区是以为加锁就能完全替代volatile。锁当然能建立可见性但前提是锁对象的加解锁要发生在同一把锁上而且加锁解锁的顺序要严格配对。如果你在线程A里synchronized(obj)改了变量而线程B读变量时用的是另一个锁对象或者根本没用锁那可见性依然没有保证。这个坑我在项目里见得太多了加锁加了一半效果等于零。4. 原子性和可见性是两个维度的区别4.1 i到底错在哪很多初学者会把“线程安全”理解为“结果正确”看到使用了volatile就认为大功告成。这里必须泼一盆冷水volatile只保证可见性和有序性不保证原子性。经典的例子是count。假设count是volatile的初始值为0两个线程各执行1000次自增按说结果应该是2000。但实际跑下来经常会小于2000。原因很简单count不是一步完成的它先读count加1再把结果写回去。两个线程可能同时读到1各自加1写回结果还是1一次自增被丢掉了。volatile管不住这种“读-改-写”的中间过程。它保证读的时候看到的是最新值写的时候也是最新值但没办法保证“在我读完之后、写进去之前别人没动过”。想要原子性得靠synchronized、ReentrantLock或者用原子类AtomicInteger、AtomicLong。这里我把三者的适用场景整理了一下方便对比手段原子性可见性适用场景性能开销volatile否是状态标志位、发布不可变对象低synchronized是是对共享资源进行复合操作中高Atomic类是是计数器、累加器、单个变量的CAS操作中4.2 用AtomicInteger做正确计数既然提到了原子类就顺手写个正确的累加案例public class AtomicCounterDemo { private static AtomicInteger counter new AtomicInteger(0); public static void main(String[] args) throws InterruptedException { Runnable task () - { for (int i 0; i 10000; i) { counter.incrementAndGet(); } }; Thread t1 new Thread(task); Thread t2 new Thread(task); t1.start(); t2.start(); t1.join(); t2.join(); System.out.println(最终计数: counter.get()); } }AtomicInteger.incrementAndGet()底层依赖CASCompare And Swap指令先比较当前值是否还是自己读到的值如果是就交换成新值否则重试。这个操作是CPU硬件层面保证的粒度高、性能好不需要锁。但也有限制它只能针对单个变量做操作如果想要实现“多个变量一起改”或“某个复合状态一起更新”还得靠锁。至于synchronized它的本质是互斥 内存屏障。进锁时刷新工作内存解锁时把修改刷回主内存。原子性由锁的排他性保证可见性由内存屏障保证一举两得。缺点就是太重如果锁竞争激烈线程切换和阻塞等待的成本会吃掉不少性能。5. synchronized、volatile、final的可见性保障细节5.1 synchronized并不只是“加把锁”很多人对synchronized的理解停留在“线程互斥进入代码块”这没有错但不够。从内存可见性的角度看synchronized还承担着刷新和失效高速缓存的工作。JVM会在synchronized块的入口和出口插入内存屏障。进入时线程的工作内存被强制失效后续读取变量必须从主内存或共享缓存重新加载退出时会把当前工作内存中修改过的共享变量强制刷新回主内存。用JMM的happens-before规则来描述就是解锁操作happens-before后续的加锁操作。这意味着即使你只是在一个synchronized方法里读了一个普通变量这个读操作也有机会以“最新值”为准因为在锁的入口过期缓存被清掉了。但请注意前提是读线程和写线程用的是同一把锁。如果是不同的锁规则不成立一切免谈。5.2 volatile到底做了什么volatile的原理可以拆成三条强制把写入操作刷新到主内存防止只留在缓存里。强制把读取操作从主内存加载防止读工作内存里的旧缓存。禁止指令重排序尤其是在这个变量附近的读写操作。前两条解决了可见性第三条解决了有序性。JVM在volatile写之前会插入StoreStore屏障写之后插入StoreLoad屏障在读操作之后插入LoadLoad和LoadStore屏障。这些屏障翻译成大白话就是在关键节点上竖一道墙不允许编译器和CPU把墙两边的指令乱序调度。用volatile有个额外的好处它与synchronized相比没有任何锁竞争开销也不涉及线程阻塞所以非常适合“一个线程写、多个线程读”的场景。比如配置开关、运行状态标志、缓存中某个不可变引用的发布都是典型应用。但还是要强调不要在volatile变量上做依赖其旧值的复合操作。典型反例是volatile int count; count;——这会丢更新以及“先检查后执行”的逻辑比如if (volatileField 10) { doSomething(); }在多线程下判断完之后字段可能已经被别的线程改掉了后续动作的决策基础已经过期。5.3 final也参与可见性你可能会觉得奇怪final字段不是不可变的吗还需要关注可见性确实需要。JMM有一条final域规则只要对象被安全地发布也就是构造方法没有把this泄漏出去那么在另一个线程中读取这个对象的final字段一定能看到初始化后的值。这是JVM在final字段写完后插入StoreStore屏障实现的目的就是保证对象构造完成之前final字段的值不会“漂移”到别的线程可见。说人话就是如果你把一个对象通过volatile引用、锁或者其他同步机制发布到其他线程其他线程不需要再次同步就能安全地读取这个对象的final字段。这在设计不可变对象时非常有用比如配置类、请求包装类把成员都设为final天然享受可见性保证省掉大量同步代码。6. 从使用方视角看Java并发类的可见性保证6.1 线程池、并发容器和锁的可见性写业务代码时多数人不会直接操作线程和volatile而是用更高层的工具线程池、并发容器、锁等。这些工具之所以“并发安全”底层都建立在happens-before规则之上。拿ThreadPoolExecutor来说你把一个任务通过execute()提交进线程池那么这个任务被执行前的所有操作对执行该任务的线程来说都是可见的。这是由execute内部的入队、唤醒操作和线程池工作线程的等待唤醒机制共同保证的。反过来说如果任务内部修改了某个共享变量而任务结束后另一个提交到线程池的任务需要读取这个变量这两者之间不一定有确定的happens-before关系。除非它们经过同一个队列、同一把锁或同一个volatile变量建立起关系。很多线上诡异数据错乱就是在不同的线程池调用之间传递可变共享状态导致的。ConcurrentHashMap同样如此。它不仅提供了线程安全的KV读写还保证了各个操作之间存在合理的happens-before边界因此你可以放心地在多线程环境下用它共享数据而不必额外加锁。常见的误区是在使用ConcurrentHashMap的同时在外面又包一层synchronized结果不仅性能下降还容易引入死锁。要学会信任并发容器已经做好的可见性保障。有件事值得留心Lock接口的可见性语义比synchronized更复杂主要因为它允许多个等待条件Condition。在使用ReentrantLock时lock.lock()与lock.unlock()之间的规则仍然成立但条件等待await()返回之后必须重新检查你关心的共享状态不能假设Condition唤醒时状态一定是最新的。6.2 单例模式里的可见性问题单例模式是面试老题也是实战中可见性Bug的高发地段。双重检查锁定Double-Checked Locking曾经是个经典的反面教材原因就出在对象构造过程中的指令重排序和可见性上。先看一个看似没问题的实现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; } }问题在于instance new Singleton()这行代码在底层会拆成分配内存、初始化字段、把引用赋值给instance。编译器和CPU可能把“初始化字段”和“赋值引用”两步调换顺序。于是线程A执行到“赋值引用”但还没完成字段初始化时线程B判断instance ! null直接返回了一个初始化到一半的对象后续访问它的字段就是错的。修复方式就是给instance加上volatileprivate static volatile Singleton instance;volatile禁止了“赋值引用”越过“初始化字段”的重排序同时保证线程B在线程A完成整个构造过程后才能看到非null的引用。这个案例可以说是理解volatile有序性的最好入门题。7. 实战排查工具与步骤7.1 遇到诡异并发Bug怎么定位在真实项目里可见性问题不会像演示代码那样直白它通常藏在纷繁复杂的调用链中且出现频率不稳定。我总结了一套排查路径每次遇到疑似并发Bug都会按这个顺序走一遍。第一步确认是否真是并发问题。把代码在单线程下跑一遍如果稳定复现那和可见性无关先把业务逻辑查清楚。多线程下才出现、且出现次数不稳定才进入下一步。第二步锁定共享变量。审查线程之间通过哪些变量交互。重点关注没有volatile、没有被锁保护、也不是并发容器支持的普通字段。把这些变量列成清单逐一对照happens-before规则看看读写之间有没有建立可见性关系。第三步用工具观测。比较高效的工具有两个jstack查看线程栈确认线程是不是卡在某个循环或等待点以及JIT编译日志通过-XX:PrintCompilation观察热点方法是否被优化必要时配合-Xint强行跑解释模式做对照实验。如果解释模式下Bug消失、JIT模式下复现那八成跟JIT优化导致的可见性/重排序有关。第四步做最小复现。把怀疑的变量抽出来像本文第2节那样写一个最小Demo用循环压力测试跑上百遍大概率能稳定复现。复现出来后再用volatile或锁修复并验证。7.2 代码审查时重点盯的五个雷区作为约定这里分享我在评审时一定会重点留意的几个模式写完一个共享状态后只是简单赋值没有用volatile或锁后续其他线程立刻读取该状态。在循环条件里直接读取普通共享变量这类代码最容易被JIT提升读取操作导致循环无法退出。用基本类型long、double做共享读写。在32位JVM上long和double的写入可能被拆成两个32位操作出现“写了一半”的情况。虽然现代64位JVM大多数情况下可以原子写入但规范层面仍建议把这类字段声明为volatile在32位平台或跨平台场景下更不能心存侥幸。借助“无意识的同步”来传递共享变量比如因为打印方法恰好是synchronized就依赖它刷缓存。今天能跑换一个打印实现就崩。对象发布时泄漏了this导致别的线程在构造完成前就看到了半成品对象。踩过这五个坑基本上你的并发代码就会比大部分项目稳一个档次。8. 最后分享一套实战经验总结我经常跟身边的人说并发编程的核心不在于背了多少API而在于能否准确回答出“两个线程之间到底是怎么建立看见关系的”。平时写代码先问自己这个共享变量写线程和读线程之间有没有happens-before如果没有加volatile如果是复合操作加锁或改用原子类如果是高阶并发容器内部的状态信任它已经处理好了。前面那个库存超卖排障最终修复只是把状态标志位改成volatile又给扣减操作换了AtomicBoolean做原子比较更新问题就消失了。回头复盘那几行代码其实任何一个环节多想一步都不至于让排查耗掉两天。还有一点建议凡是涉及线程间状态同步的代码尽量用现成的并发工具比如用AtomicBoolean.compareAndSet代替“if判断volatile赋值”用ConcurrentHashMap.compute代替“get判断后再put”。并发容器自带的复合操作比你手写的两步走要可靠得多不要总觉得直接操作底层的volatile更酷能用工具就用工具。另外想多说一句可见性问题往往只在特定硬件和JVM版本下暴露测试环境里跑一天可能都安然无恙一到生产环境就原形毕露。遇到这类问题别急着加锁先把时间线理清楚找到那个“写”和“读”没有关联的点。能明确定位到根因代码修改通常就是一行volatile的事定位不到根因就算把每次访问都包一层synchronized也未必能彻底解决问题。实践出真知找一台多核机器把文中的示例代码跑起来再用-XX:PrintCompilation看看JIT的变化你对可见性的理解会拔高一个层级。
在并发编程这块待久了你会发现真正让人头疼的不是死锁也不是线程池参数而是一些看起来“明明没问题”的代码跑起来却像中了邪一样随机出错。我印象最深的一次是在排查一个库存扣减的偶发超卖问题业务逻辑加了对账、落了日志、上了事务但在压力测试下就是会有几条数据不合预期。最后定位下来问题恰恰出在一个普通布尔字段的读写上——多个线程对同一个标志位的修改压根没有在第一时间同步到其他线程的“眼睛”里。这背后牵扯的就是Java并发中必须吃透的两件事线程安全与内存可见性。这篇文章不会堆概念而是从一次真实的排障现场出发把Java内存模型JMM、volatile、synchronized、原子类这些关键字逐个摆到台面上用可运行的代码案例告诉你为什么会有可见性问题怎么复现它又该怎么修。同时会把我在实际项目中踩过的一些坑、用过的排查工具和一些“看起来写了等于没写”的坑爹写法都一并分享出来。无论你是刚接触多线程的初学者还是已经写过一段时间并发代码的开发者相信看完都会有收获。1. 先从三个并发问题的根源说起1.1 原子性、可见性、有序性到底是什么很多人把线程安全等同于“加了锁就安全”这话只说对了一半。并发场景下的Bug通常逃不出三个维度原子性、可见性、有序性。原子性解决的是“操作不被中断”的问题。比如count这行代码看起来是一条语句底层其实是“读取-修改-写入”三步多线程同时执行时就会互相穿插把中间结果搞丢。可见性解决的是“一个线程改了另一个线程能不能立刻看到”的问题。有序性解决的是“代码执行顺序和指令顺序是否一致”的问题编译器、CPU都可能为了优化而重排序。这三个维度经常被混为一谈导致很多人用错了手段。比如你给一个布尔标志位加了synchronized本意是想保证可见性这当然有效但代价偏大又比如你用AtomicInteger保证了原子性却没注意被它引用的其他普通字段的可见性结果还是会翻车。所以排查并发问题时先要问自己一句这个Bug到底是哪个维度出的问题方向错了后面的修法肯定也错。1.2 CPU缓存与Java线程的“隔空喊话”要理解可见性先得知道数据在硬件上是怎么流转的。现代CPU无论多少核运算速度都快得离谱但内存却相对慢得多。为了平衡速度差CPU里加了多层缓存L1、L2、L3。每个核心各自持有部分缓存同时又共享最后一级缓存和主内存。线程运行在CPU核心上读变量时不一定直接去主内存拿而是优先读本核心的缓存写变量时也不一定立刻刷回主内存而是先落在缓存里等到某个时机再同步。这就带来了一个天然的问题核心A改了变量的值核心B如果还扎在自己的缓存里读旧值两边看到的数据就不一致。Java线程模型在设计时参考了这套硬件结构给出了自己的抽象每条线程有自己的“工作内存”共享变量存放在“主内存”。工作内存对应CPU缓存或寄存器主内存对应物理内存。具体什么时候刷新、什么时候失效JVM规范没有强制要求在每条指令上保证而是定义了一套规则——这就是Java内存模型的核心作用。所以“线程A写了一个变量线程B马上就能看到”在Java里从来都不是默认行为需要开发者在代码层面主动去建立联系。2. 用代码复现一个经典的可见性陷阱2.1 一个可能“永远停不下来”的循环纸上谈兵没意思直接来个现场实验。下面这段代码很有代表性public class VisibilityDemo { private static boolean flag true; public static void main(String[] args) throws InterruptedException { Thread worker new Thread(() - { long count 0; while (flag) { count; } System.out.println(线程退出共执行了 count 次循环); }); worker.start(); Thread.sleep(1000); flag false; System.out.println(主线程已将flag置为false); } }逻辑上主线程睡1秒后把flag改成falseworker线程应该很快跳出循环并打印退出信息。但你在你的电脑上跑一下大概率看到的情况是主线程打印完了worker线程却一直不打印退出消息程序卡在那里不退出。为什么会这样因为worker线程的循环体里每次循环都会去读flag。第一次读的时候发现是true于是进入循环进入循环后JIT编译器会做一个优化把flag的读取“提升”到循环外相当于循环变成了if (flag) { while(true) count; }——flag只读了一次之后不管主线程改不改worker线程都看不见。这种优化在单线程环境下完全没有问题因为单线程里flag在循环中确实没被修改。但到了多线程环境中它直接打破了可见性的预期。你可能会说“我的循环体里有别的操作比如打印日志会不会就不会被提升了”不一定。JIT优化极其细致它会分析循环体里哪些操作有副作用、哪些可以挪动。更靠谱的做法是显式地把线程间的共享关系声明清楚。2.2 为什么加了打印偶尔就“正常”了这个问题我回答过很多次也经常被追问“我给循环体里加一行System.out.println(count)程序就能正常退出是不是说明问题消失了”不问题还在。加打印后正常退出的原因通常是System.out内部是synchronized的println执行时经过了锁和内存屏障顺带触发了工作内存和主内存的同步这个效应“捎带”着把flag的新值刷新到了worker线程的可见范围。但这是副作用不是保证。你换个平台、换个JVM参数、换个时机行为可能又不一样。用副作用去“碰巧”解决并发问题是开发的大忌今天能跑不代表明天能跑。想彻底解决最直接的方案是把flag声明为volatile。volatile保证了对该变量的写操作立即刷新到主内存读操作则直接从主内存读同时禁止编译器和CPU对它做重排序。改完之后worker线程就能及时感知到变化并退出循环。这个关键字就是为这类“状态标志位”的场景设计的轻量、无锁性能代价远小于synchronized。private static volatile boolean flag true;后面我们在第5节会具体展开volatile的语义细节包括它什么时候能用、什么时候不能用。这里先记住一个结论多个线程共享一个状态标志来控制流程时优先考虑volatile。3. Java内存模型与happens-before规则3.1 JMM不只是规范更是排查问题的“标尺”很多人觉得JMM就是教科书上的一段概念工作中用不上。实际上我后来在团队里做代码审查时都是直接拿JMM的规则去对照一眼就能看出某个字段该不该加volatile、某个线程间协作能不能成立。Java内存模型规定所有共享变量存储在主内存每条线程有自己的工作内存。线程对共享变量的所有操作都必须在工作内存中进行不能直接读写主内存。不同线程之间无法直接访问对方的工作内存只能通过主内存来传递数据。这套模型意味着只要两个线程之间没有建立某种“协调规则”那么一个线程对变量的修改对另一个线程来说就是不可预知的。那“协调规则”在Java里具体长什么样就是happens-before关系。如果操作A happens-before操作B那么A的执行结果对B是可见的。JMM里总结了若干条规则程序次序规则、监视器锁规则、volatile变量规则、传递性、Thread.start()规则、Thread.join()规则等。拿监视器锁规则来说同一个锁上解锁操作happens-before后续的加锁操作。意思是线程A释放锁之前对共享变量做的所有修改线程B获取到同一把锁之后一定能看见。这就是为什么synchronized不仅能保证原子性也能保证可见性——它不是玄学而是有明确规则背书。用的时候心里要有数别只把它当“互斥工具”使。3.2 把happens-before关系画在脑子里我在实际分析并发问题时习惯把参与协作的线程和操作画成一条时间线然后逐条套happens-before规则。最常用的三条是对volatile变量的写操作happens-before后续对同一个volatile变量的读操作。对synchronized锁的解锁操作happens-before后续对同一个锁的加锁操作。Thread.start()的调用happens-before被启动线程中的任何操作被启动线程中的所有操作happens-beforeThread.join()返回。这三条记住了大部分可见性问题都能定位。比如前面那个循环案例主线程写flagworker线程读flag两者之间没有任何happens-before关系因此主线程的写入不保证对worker线程可见。声明成volatile后写flag和读flag之间就建立了happens-before关系问题迎刃而解。有一个常见的误区是以为加锁就能完全替代volatile。锁当然能建立可见性但前提是锁对象的加解锁要发生在同一把锁上而且加锁解锁的顺序要严格配对。如果你在线程A里synchronized(obj)改了变量而线程B读变量时用的是另一个锁对象或者根本没用锁那可见性依然没有保证。这个坑我在项目里见得太多了加锁加了一半效果等于零。4. 原子性和可见性是两个维度的区别4.1 i到底错在哪很多初学者会把“线程安全”理解为“结果正确”看到使用了volatile就认为大功告成。这里必须泼一盆冷水volatile只保证可见性和有序性不保证原子性。经典的例子是count。假设count是volatile的初始值为0两个线程各执行1000次自增按说结果应该是2000。但实际跑下来经常会小于2000。原因很简单count不是一步完成的它先读count加1再把结果写回去。两个线程可能同时读到1各自加1写回结果还是1一次自增被丢掉了。volatile管不住这种“读-改-写”的中间过程。它保证读的时候看到的是最新值写的时候也是最新值但没办法保证“在我读完之后、写进去之前别人没动过”。想要原子性得靠synchronized、ReentrantLock或者用原子类AtomicInteger、AtomicLong。这里我把三者的适用场景整理了一下方便对比手段原子性可见性适用场景性能开销volatile否是状态标志位、发布不可变对象低synchronized是是对共享资源进行复合操作中高Atomic类是是计数器、累加器、单个变量的CAS操作中4.2 用AtomicInteger做正确计数既然提到了原子类就顺手写个正确的累加案例public class AtomicCounterDemo { private static AtomicInteger counter new AtomicInteger(0); public static void main(String[] args) throws InterruptedException { Runnable task () - { for (int i 0; i 10000; i) { counter.incrementAndGet(); } }; Thread t1 new Thread(task); Thread t2 new Thread(task); t1.start(); t2.start(); t1.join(); t2.join(); System.out.println(最终计数: counter.get()); } }AtomicInteger.incrementAndGet()底层依赖CASCompare And Swap指令先比较当前值是否还是自己读到的值如果是就交换成新值否则重试。这个操作是CPU硬件层面保证的粒度高、性能好不需要锁。但也有限制它只能针对单个变量做操作如果想要实现“多个变量一起改”或“某个复合状态一起更新”还得靠锁。至于synchronized它的本质是互斥 内存屏障。进锁时刷新工作内存解锁时把修改刷回主内存。原子性由锁的排他性保证可见性由内存屏障保证一举两得。缺点就是太重如果锁竞争激烈线程切换和阻塞等待的成本会吃掉不少性能。5. synchronized、volatile、final的可见性保障细节5.1 synchronized并不只是“加把锁”很多人对synchronized的理解停留在“线程互斥进入代码块”这没有错但不够。从内存可见性的角度看synchronized还承担着刷新和失效高速缓存的工作。JVM会在synchronized块的入口和出口插入内存屏障。进入时线程的工作内存被强制失效后续读取变量必须从主内存或共享缓存重新加载退出时会把当前工作内存中修改过的共享变量强制刷新回主内存。用JMM的happens-before规则来描述就是解锁操作happens-before后续的加锁操作。这意味着即使你只是在一个synchronized方法里读了一个普通变量这个读操作也有机会以“最新值”为准因为在锁的入口过期缓存被清掉了。但请注意前提是读线程和写线程用的是同一把锁。如果是不同的锁规则不成立一切免谈。5.2 volatile到底做了什么volatile的原理可以拆成三条强制把写入操作刷新到主内存防止只留在缓存里。强制把读取操作从主内存加载防止读工作内存里的旧缓存。禁止指令重排序尤其是在这个变量附近的读写操作。前两条解决了可见性第三条解决了有序性。JVM在volatile写之前会插入StoreStore屏障写之后插入StoreLoad屏障在读操作之后插入LoadLoad和LoadStore屏障。这些屏障翻译成大白话就是在关键节点上竖一道墙不允许编译器和CPU把墙两边的指令乱序调度。用volatile有个额外的好处它与synchronized相比没有任何锁竞争开销也不涉及线程阻塞所以非常适合“一个线程写、多个线程读”的场景。比如配置开关、运行状态标志、缓存中某个不可变引用的发布都是典型应用。但还是要强调不要在volatile变量上做依赖其旧值的复合操作。典型反例是volatile int count; count;——这会丢更新以及“先检查后执行”的逻辑比如if (volatileField 10) { doSomething(); }在多线程下判断完之后字段可能已经被别的线程改掉了后续动作的决策基础已经过期。5.3 final也参与可见性你可能会觉得奇怪final字段不是不可变的吗还需要关注可见性确实需要。JMM有一条final域规则只要对象被安全地发布也就是构造方法没有把this泄漏出去那么在另一个线程中读取这个对象的final字段一定能看到初始化后的值。这是JVM在final字段写完后插入StoreStore屏障实现的目的就是保证对象构造完成之前final字段的值不会“漂移”到别的线程可见。说人话就是如果你把一个对象通过volatile引用、锁或者其他同步机制发布到其他线程其他线程不需要再次同步就能安全地读取这个对象的final字段。这在设计不可变对象时非常有用比如配置类、请求包装类把成员都设为final天然享受可见性保证省掉大量同步代码。6. 从使用方视角看Java并发类的可见性保证6.1 线程池、并发容器和锁的可见性写业务代码时多数人不会直接操作线程和volatile而是用更高层的工具线程池、并发容器、锁等。这些工具之所以“并发安全”底层都建立在happens-before规则之上。拿ThreadPoolExecutor来说你把一个任务通过execute()提交进线程池那么这个任务被执行前的所有操作对执行该任务的线程来说都是可见的。这是由execute内部的入队、唤醒操作和线程池工作线程的等待唤醒机制共同保证的。反过来说如果任务内部修改了某个共享变量而任务结束后另一个提交到线程池的任务需要读取这个变量这两者之间不一定有确定的happens-before关系。除非它们经过同一个队列、同一把锁或同一个volatile变量建立起关系。很多线上诡异数据错乱就是在不同的线程池调用之间传递可变共享状态导致的。ConcurrentHashMap同样如此。它不仅提供了线程安全的KV读写还保证了各个操作之间存在合理的happens-before边界因此你可以放心地在多线程环境下用它共享数据而不必额外加锁。常见的误区是在使用ConcurrentHashMap的同时在外面又包一层synchronized结果不仅性能下降还容易引入死锁。要学会信任并发容器已经做好的可见性保障。有件事值得留心Lock接口的可见性语义比synchronized更复杂主要因为它允许多个等待条件Condition。在使用ReentrantLock时lock.lock()与lock.unlock()之间的规则仍然成立但条件等待await()返回之后必须重新检查你关心的共享状态不能假设Condition唤醒时状态一定是最新的。6.2 单例模式里的可见性问题单例模式是面试老题也是实战中可见性Bug的高发地段。双重检查锁定Double-Checked Locking曾经是个经典的反面教材原因就出在对象构造过程中的指令重排序和可见性上。先看一个看似没问题的实现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; } }问题在于instance new Singleton()这行代码在底层会拆成分配内存、初始化字段、把引用赋值给instance。编译器和CPU可能把“初始化字段”和“赋值引用”两步调换顺序。于是线程A执行到“赋值引用”但还没完成字段初始化时线程B判断instance ! null直接返回了一个初始化到一半的对象后续访问它的字段就是错的。修复方式就是给instance加上volatileprivate static volatile Singleton instance;volatile禁止了“赋值引用”越过“初始化字段”的重排序同时保证线程B在线程A完成整个构造过程后才能看到非null的引用。这个案例可以说是理解volatile有序性的最好入门题。7. 实战排查工具与步骤7.1 遇到诡异并发Bug怎么定位在真实项目里可见性问题不会像演示代码那样直白它通常藏在纷繁复杂的调用链中且出现频率不稳定。我总结了一套排查路径每次遇到疑似并发Bug都会按这个顺序走一遍。第一步确认是否真是并发问题。把代码在单线程下跑一遍如果稳定复现那和可见性无关先把业务逻辑查清楚。多线程下才出现、且出现次数不稳定才进入下一步。第二步锁定共享变量。审查线程之间通过哪些变量交互。重点关注没有volatile、没有被锁保护、也不是并发容器支持的普通字段。把这些变量列成清单逐一对照happens-before规则看看读写之间有没有建立可见性关系。第三步用工具观测。比较高效的工具有两个jstack查看线程栈确认线程是不是卡在某个循环或等待点以及JIT编译日志通过-XX:PrintCompilation观察热点方法是否被优化必要时配合-Xint强行跑解释模式做对照实验。如果解释模式下Bug消失、JIT模式下复现那八成跟JIT优化导致的可见性/重排序有关。第四步做最小复现。把怀疑的变量抽出来像本文第2节那样写一个最小Demo用循环压力测试跑上百遍大概率能稳定复现。复现出来后再用volatile或锁修复并验证。7.2 代码审查时重点盯的五个雷区作为约定这里分享我在评审时一定会重点留意的几个模式写完一个共享状态后只是简单赋值没有用volatile或锁后续其他线程立刻读取该状态。在循环条件里直接读取普通共享变量这类代码最容易被JIT提升读取操作导致循环无法退出。用基本类型long、double做共享读写。在32位JVM上long和double的写入可能被拆成两个32位操作出现“写了一半”的情况。虽然现代64位JVM大多数情况下可以原子写入但规范层面仍建议把这类字段声明为volatile在32位平台或跨平台场景下更不能心存侥幸。借助“无意识的同步”来传递共享变量比如因为打印方法恰好是synchronized就依赖它刷缓存。今天能跑换一个打印实现就崩。对象发布时泄漏了this导致别的线程在构造完成前就看到了半成品对象。踩过这五个坑基本上你的并发代码就会比大部分项目稳一个档次。8. 最后分享一套实战经验总结我经常跟身边的人说并发编程的核心不在于背了多少API而在于能否准确回答出“两个线程之间到底是怎么建立看见关系的”。平时写代码先问自己这个共享变量写线程和读线程之间有没有happens-before如果没有加volatile如果是复合操作加锁或改用原子类如果是高阶并发容器内部的状态信任它已经处理好了。前面那个库存超卖排障最终修复只是把状态标志位改成volatile又给扣减操作换了AtomicBoolean做原子比较更新问题就消失了。回头复盘那几行代码其实任何一个环节多想一步都不至于让排查耗掉两天。还有一点建议凡是涉及线程间状态同步的代码尽量用现成的并发工具比如用AtomicBoolean.compareAndSet代替“if判断volatile赋值”用ConcurrentHashMap.compute代替“get判断后再put”。并发容器自带的复合操作比你手写的两步走要可靠得多不要总觉得直接操作底层的volatile更酷能用工具就用工具。另外想多说一句可见性问题往往只在特定硬件和JVM版本下暴露测试环境里跑一天可能都安然无恙一到生产环境就原形毕露。遇到这类问题别急着加锁先把时间线理清楚找到那个“写”和“读”没有关联的点。能明确定位到根因代码修改通常就是一行volatile的事定位不到根因就算把每次访问都包一层synchronized也未必能彻底解决问题。实践出真知找一台多核机器把文中的示例代码跑起来再用-XX:PrintCompilation看看JIT的变化你对可见性的理解会拔高一个层级。
