我在好几个项目里都遇过这种场景线上接口偶尔返回奇怪的数据多加了几行日志想排查结果日志顺序还乱了。代码review了好几遍逻辑明明没问题最后定位到的问题全是并发下“看不见”和“乱序”惹的祸。Java内存模型JMM这东西面试常问但真正在写代码时能意识到它在起作用的人不多。这篇内容我想从CPU底层的缓存机制讲起把JMM的核心规则拆开揉碎再落到几个并发实战里高频踩坑的场景比如DCL要不要加volatile、long型数据为什么会读到半个值、怎么用工具把死锁和热点锁揪出来。如果你写过并发代码但没系统捋过底层逻辑或者准备深入JUC源码这篇会挺对路。1. 先从最反直觉的现象说起代码顺序和执行顺序本来就两码事很多开发者第一次对并发产生敬畏不是因为锁用错了而是因为一个“不可能出现”的结果出现了线程序号明明按顺序写了实际跑出来却反了。或者是两个线程各自修改一个共享boolean变量主线程读取的时候读了半天还是旧值。这类问题的根子不在Java代码层面而在CPU硬件层面上。现代CPU为了填满流水线自己就会调整指令执行顺序这叫指令级重排序。多核CPU里每个核心又有各自的L1、L2缓存核心间通过缓存一致性协议同步数据但同步是有延迟的。Java代码写在字节码里是一条条顺序指令到了CPU流水线里早就不按你源码的顺序跑了。举一个我在模拟项目X里复现过的经典例子。两个线程一个执行“设置flag true然后输出”另一个执行“等待flag变true后输出”。如果不用任何同步手段第二个线程可能永远等不到flag变成true哪怕第一个线程里明明先执行了赋值。有同事第一反应是“内存不够了”其实不是是CPU缓存里flag的新值还没刷到主内存另一个核心上的线程读到的还是自己缓存里那份初始值。这里就牵扯出两个核心概念可见性和有序性。可见性是一个线程对共享变量的修改什么时候能被另一个线程看见有序性是指代码里的先后关系最终在CPU上是否还是那个先后关系。JMM这套规范本质上就是在回答这两个问题因为Java跑在各种硬件上不能只针对一种CPU缓存模型写逻辑所以JVM在中间做了一层抽象每个线程有自己的工作内存对应CPU缓存抽象共享变量存在主内存对应物理内存抽象。线程不能直接改主内存只能先读到工作内存改完再刷回主内存。注意JMM里的“主内存”“工作内存”是抽象概念不是真的指JVM内存结构里的堆和栈。很多文章把堆栈和JMM混着说容易绕晕。堆栈是JVM运行时数据区的划分JMM关心的是线程和共享数据之间的交互规则。也就是说你看到“代码A先于代码B执行”的源码顺序在CPU实际执行时可能被重排成B先执行。只要重排不影响单线程语义CPU和编译器就能放心大胆地做优化。这在单线程下完全没问题但一到多线程如果没做同步别的线程看到的就是一堆乱序操作。很多人想不通为什么并发代码会出这种诡异问题就是还没建立起“源码顺序不等于CPU执行顺序”这个前提。后面所有实战场景基本都是围绕这两个问题展开的。如果你之前只学了synchronized怎么用、Lock怎么用没细想过它们底层到底禁了什么那我建议把前面这部分当锚点后面每讲一个机制都回来对照一下它管的是可见性还是有序性还是两个都管。2. CPU缓存机制到缓存一致性协议JMM的设计源头要理解JMM为什么规定“volatile禁用重排序”“synchronized要管可见性”得先弄明白CPU硬件上这套机制是怎么工作的。很多并发问题在硬件层面其实是同一个问题的不同表现。2.1 CPU缓存的层次设计为什么要加缓存CPU的运算速度和内存的读写速度之间差距非常大。假设CPU每秒能执行几十亿条指令内存的响应延迟却高出好几个数量级如果每执行一条指令都去内存读数据CPU大部分时间是在等数据。所以现代CPU普遍采用多级缓存架构L1缓存属于单个核心访问延迟大约2到4个时钟周期L2缓存通常也被核心独享或者双核共享延迟十几到二十几个周期L3缓存是多个核心共享的延迟更大但容量也更大。越靠近核心的缓存速度越快但空间越小。这个设计和HTTP缓存、Redis缓存的设计思路一模一样把高频访问的数据放到离计算最近的地方。问题也来了既然每个核心有私有的L1/L2一个共享变量被多个核心各自缓存了副本某核心改了它的值另一个核心什么时候能感知到这就涉及缓存之间怎么保持一致的问题。2.2 缓存一致性协议核心间如何对齐数据最常提到的缓存一致性协议是MESIModified、Exclusive、Shared、Invalid协议。它给每个缓存行加了状态标记Modified当前核心改过这个缓存行数据只在本核心缓存里有效和主内存不一致。Exclusive当前核心独占这个缓存行数据没有别处缓存和主内存一致。Shared多个核心都缓存了这一行数据当前没有核心修改大家看到的都是主内存里一致的版本。Invalid数据失效了需要读的时候得重新从其他缓存或主内存加载。当某个核心想修改一个Shared状态的缓存行时需要先发送一个失效通知让其他核心把对应缓存行置为Invalid。收到所有确认后本核心才把状态改成Modified执行写入。这种“先失效、后写入”的机制保证了任意时刻只有一个核心能持有可写副本。但性能优化总是层层加码的为了不每次都同步等待其他核心的确认CPU引入了写缓冲器和无效队列。也就是说写入操作先放到一个缓冲里CPU继续干后面的事不等其他核心真正确认失效完成。这个优化的代价就是其他核心可能在短时间内仍然读旧值甚至在时序上观察到颠倒的写入效果。从编程者的角度这等价于我明明在代码里先更新了A再更新B另一个线程却可能先看到B的新值、后看到A的新值。这可能造成非常隐蔽的业务错误。JMM里规定的各种happens-before规则就是在约束JVM和CPU哪些优化可以做哪些地方必须牺牲性能保证顺序。2.3 内存屏障程序与CPU优化之间的一堵墙JVM最终是通过内存屏障指令来约束CPU行为的。内存屏障是一类特殊的CPU指令分为读屏障、写屏障、全屏障等。它们的作用说白了就是两件事防止指令跨越屏障乱序同时让CPU缓存与主内存之间按需同步。当变量被volatile修饰时JVM生成的指令会在合适的位置插入屏障让volatile写之前的普通读写不能跑到volatile写之后volatile读之后的普通读写不能跑到volatile读之前。这就在硬件层面实现了“禁止重排序”的语义。synchronized锁的释放和获取底层也依赖屏障来冲刷和刷新线程的工作内存。这里多说一句很多人会背“MESI协议能保证缓存一致性”然后就很困惑——既然协议保证了为什么还有可见性问题关键在于协议保证的是“缓存行最终一致”但没有强制“立即可见”而且写缓冲器和无效队列这些优化手段让“最终一致”的时间窗口变得很大。这个窗口期就是并发bug的温床。JMM对Java代码和JVM实现提出要求相当于规定了一个“合法可见范围”的边界而内存屏障是这个边界的物理具体化。聊到这一步如果你能理解“代码层面加volatile和synchronized最终目的是约束CPU的优化行为”后面看JDK并发包的源码就会有豁然开朗的感觉。3. JMM的核心抽象主内存、工作内存与八种原子操作JMM定义了一套线程与内存交互的规则主体是一张表和八个原子操作。这张表看着像教科书里的枯燥内容但把它翻译成模拟硬件行为会立刻明白Java的线程为什么能跨平台保持相对一致的并发语义。JMM规定线程对共享变量的所有操作都必须在工作内存里进行工作内存里存的是变量在主内存中的副本。线程A改了工作内存副本必须按规则刷回主内存线程B要读共享变量必须先到主内存把值拉到自己的工作内存。问题集中在两个时间点改完什么时候刷回读前什么时候从主内存拉最新值JMM定义的八个操作是lock、unlock、read、load、use、assign、store、write。名字很抽象但把它们串成一条链路就清楚了线程要读一个共享变量时先read从主内存读再load加载到工作内存再use工作内存的值交给执行引擎写的时候先assign执行引擎赋值给工作内存再store把工作内存的值传回主内存再write写入主内存。JMM为这八个操作制定了规则并不允许随便乱来。但这些操作是一组“最低层契约”JVM具体实现时未必按这种一步一操作的方式落地更多是借助内存屏障直接做到等价的顺序保证。笔试和面试里如果被问到重点是能说清这八个操作的方向和执行约束而不是死记单词。实际开发里这套抽象到底有什么用你可以用这套框架去诊断一个并发bug。比如一个long类型变量在线程A里写了高32位和低32位线程B读的时候由于没有同步可能读到“半个写、半个旧”的组合。这种问题在过去32位JVM上还很常见现在64位JVM对long和double的写入已经保证了原子性但如果是引用类型的字段或者更复杂的对象结构依然可能出现“看到一半状态”的情况。用这套抽象来解释就是读线程load的时间点卡在了写线程store和write之间的某个位置。不过要强调一点JMM本身只保证“安全发布”相关的语义不保证你看到的状态是“绝对最新”。共享变量的变化很多但只有通过锁或volatile建立同步关系线程之间才知道彼此改了哪个版本。这也是为什么很多并发工具类的字段都会用volatile修饰JDK里AQS的state字段就是一个典型它写volatile和读volatile的边界正好和锁的获取释放语义对上。4. happens-before原则JMM里最值得背下来的规则清单JMM最核心的部分不是那幅主内存工作内存图而是happens-before原则。这是一组规则定义了“如果操作A happens-before操作B则A的结果对B可见且A的执行顺序先于B”。这是程序员在编写并发代码时唯一不用去理解CPU细节就能直接套用的判断工具。happens-before规则一共有以下这些程序顺序规则同一个线程中前面的操作happens-before后面的操作。注意这是“同一个线程内”线程之间的顺序不能靠这个推断。监视器锁规则对一个锁的解锁happens-before随后对这个锁的加锁。这就是synchronized保证可见性的本质线程A退出同步块之前修改的东西线程B进入同一个锁的同步块后一定能看到。volatile变量规则对一个volatile变量的写操作happens-before后续对这个变量的读操作。注意是“后续读”才能看到写如果读发生在写之前那自然看不到。线程启动规则Thread对象的start()方法happens-before被启动线程中的任意动作。也就是说线程启动前对共享变量的修改在这个新线程里一定能看到。线程终止规则线程中的任意动作happens-before另一个线程检测到这个线程终止通过join或isAlive返回false。中断规则对线程调用interrupt()方法happens-before被中断线程检测到中断事件抛出InterruptedException或通过isInterrupted查询。传递性如果A happens-before BB happens-before C那么A happens-before C。用这套规则分析代码时会发现确认一个变量在两个线程之间是否安全共享其实就是找一条happens-before链。链上每一个环节都需要有锁、volatile或线程边界来支撑。如果找不到这条链那这个变量的读写就是数据竞争读出来的结果在JMM层面就是未定义行为你不能假设它一定是旧值也不能假设一定是新值它就是“薛定谔”的。有一个常见的误读是既然volatile能保证可见性那把所有共享变量都声明成volatile不就完了这里要掰开说清楚。volatile的功能是可见性和有序性它不保证复合操作的原子性比如count这种“读-改-写”操作volatile管不了。多个线程同时对volatile变量执行自增结果照样会丢更新。真正的原子性还得靠synchronized、Atomic类或显式锁。再有一个误区是把“线程安全的单例”简单理解成“加了双重检查就行”。很多人写的DCL双重检查锁定单例没加volatile这段代码在很多JVM上跑得好好的为啥因为碰巧运行环境的JIT没有做足够激进的重排序。但你没法保证换个JVM版本或换台服务器还安全。DCL的隐患在于外层判断instance ! null时就返回了这个引用如果构造对象的指令被重排序另一个线程可能拿到一个“还没有完成构造”的对象。JMM规定volatile的写读具有屏障语义就是为了禁止这种重排。所以DCL的正确写法是instance字段加volatile或者直接改用静态内部类方式更省心。5. 实战里最常见的几个并发坑数据竞争、DCL、long/double可见性看再多的理论都不如把典型坑梳理一遍来得实在。以下这几个场景我基本在每个并发相关的项目评审里都会遇到属于“99%的开发者都踩过”的范畴。5.1 数据竞争加了锁不等于万事大吉最常见的一种错误是A线程在synchronized块里改共享变量B线程读这个变量时没加同一个锁。很多人的理由是“读取操作不需要改数据所以不用锁”。但从JMM角度看B线程的读跟A线程的写之间没有happens-before关联B完全可以读到一个中间状态或者旧值。反例很容易落地验证你写个小程序开两个线程一个改数据一个频繁读不加同步时确实偶尔能读到过期值加锁后读到的值就稳定了。这类问题在业务上挺隐晦的因为不是必现。可能本地环境跑一百次都不出错到了生产环境高并发下某一次调度窗口不对就暴露了。排查时最有效的办法是围着共享变量找所有读写点逐个确认有没有同一把锁或volatile撑着。5.2 双重检查锁定DCL为什么必须加volatileDCL单例的代码短小精悍但非常值得单独讲。常见写法是这样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; } }问题出在new Singleton()这一步。它不是一个原子操作从JVM语义上可以拆成三件事分配内存空间。在内存上构造对象执行构造函数。把instance引用指向这块内存。如果CPU或JIT做了重排序把第3步提前到第2步之前另一个线程恰好在这里执行了外层判断发现instance不是null就直接返回了。但这个对象可能还没执行构造函数字段都还是默认值。使用方拿到这个半成品轻则读到默认值重则直接空指针。给instance加上volatile就是在写引用和读引用之间建立happens-before关系禁止对volatile写操作之前操作的“排序”。很多老项目里有这种写法线上一直没出事那是运气好不代表正确。我见过有人为了兼容老代码直接把这个单例改成枚举实现业务方根本无感知。5.3 long/double的可见性与中间态问题JMM早期规范不太强制保证long和double读写的原子性因为32位JVM上一个long占64位要拆成两次32位操作执行就可能出现读到的值是高32位来自旧值、低32位来自新值的组合。现代64位JVM和主流处理器上实际实现已经保证了原子性依赖这个演进其实是可以的。但如果你想写一段无论未来JVM怎么优化行为都安全的代码还是应该用volatile或锁来保证long/double的原子读写。这和前面提到的“数据竞争”其实是一条线上的问题一个偏硬件一个偏语言规范。很多并发bug表面是long读出了奇怪值深层原因仍然是读线程和写线程没有同步关系。5.4 典型的可见性演示样例用下面的这种小模板可以快速复现可见性问题。注意循环次数不能太少否则大概率不等JIT优化完成就结束了。public class VisibilityDemo { private static boolean flag false; private static int number 0; public static void main(String[] args) throws InterruptedException { new Thread(() - { while (!flag) { // 空转等待flag变化 } System.out.println(reader: number number); }).start(); Thread.sleep(100); new Thread(() - { number 42; flag true; }).start(); } }写线程把number改成42再把flag置true。如果flag不加volatile读线程的循环可能一直读不到新值或者读到了flag新值但number读到的仍然是0。后者为什么也会出现因为flag的写和读之间没有建立happens-before关系写线程里对number的更新不一定在flag更新前被别的线程看到——正好对应前面说的重排序问题。把flag改成volatile后不只flag本身可见了写线程里在flag写之前发生的所有普通变量写操作都对flag读之后的读线程可见。这就是volatile写-读具备的“重排序限制”带来的附加能力。很多时候我们只用volatile管一个状态位实际上它还捎带纠正了周边变量的可见性。不少开源框架利用这个特性做“轻量级状态发布”比用一个锁开销小得多。6. synchronized和volatile底层做了什么从字节码到锁升级很多读者学会了synchronized用法但对它怎么和JMM的规则映射到一起还是模糊的。这里我把它拆成两个层面字节码层面JVM具体实现层面。6.1 synchronized的字节码表现synchronized同步块编译后会在进入前加monitorenter指令在退出后加monitorexit指令异常路径上也会隐式补一个monitorexit保证锁一定释放。这就是JVM要保证的“一个锁的释放happens-before随后的获取”在字节码层面的具体落点。如果锁的是实例方法那锁对象就是this如果是静态方法锁对象是类对象。方法级别的synchronized不用在字节码里显式生成monitorenter/monitorexit由方法访问标志里的ACC_SYNCHRONIZED来触发效果和排队进入同步块一样。6.2 偏向锁到轻量级锁到重量级锁的升级路径在JDK 8及之后的主流商用JVM里synchronized锁大体会经历几个状态无锁、偏向锁、轻量级锁、重量级锁。JVM在JIT编译后会依据竞争情况做锁优化。偏向锁假设锁只被一个线程拥有线程重入时只做一次CAS记录线程ID开销极低。如果另一个线程也来竞争偏向模式会撤销升级成轻量级锁。轻量级锁之间通过CAS自旋争抢锁记录自旋适合锁持有时间很短、竞争不激烈的场景。一旦自旋次数超限或等待线程数过多就升级成重量级锁此时未抢到锁的线程会进入操作系统内核态阻塞涉及用户态和内核态切换开销最大。很多人纠结锁升级过程要不要背我的建议是别死记阈值参数版本不同差异很大。重点理解设计思路JVM用低开销的乐观锁方案兜底单线程竞争场景再用自旋兜底短竞争场景最后才用重量级锁兜底高竞争场景。理解了这条优化链你在写并发代码时自然知道“不要长时间占用锁”“锁粒度要小”是因为什么。6.3 volatile的屏障语义volatile变量在字节码层面没什么特殊指令只是访问标记多了ACC_VOLATILE。但它影响的是JIT生成的机器码volatile写之后JVM会插入一个StoreStore屏障加StoreLoad屏障volatile读之前会插入LoadLoad屏障加LoadStore屏障。具体类型可能随平台调整但核心目标都是一样的禁止volatile写与之前普通写重排序。禁止volatile读与之后普通读重排序。禁止volatile写与之后volatile读重排序。如果你是第一次接触屏障这个东西把它理解成“一堵墙”就行指令不能越过这堵墙乱窜顺序被固定住同时缓存同步也被触发。6.4 锁、volatile、CAS、原子类怎么选日常写并发代码不一定非要直接上synchronized或volatile工具盒里还有其他选择。它们各自的适用场景和代价差别挺大机制保证的语义性能特点适用场景synchronized互斥、可见性、有序性锁升级后开销大但JVM内置优化好临界区逻辑复杂或对锁粒度要求不高volatile可见性、有序性不保证原子性开销较小无上下文切换状态标志、引用发布、计数器配合CASCAScompareAndSet原子更新单个变量自旋高竞争时CPU开销大原子计数器、并发状态机Atomic类基于CAS封装保证原子性和可见性无锁但竞争激烈时可能出现活锁倾向简单原子变量操作ReentrantLock互斥、可见性、有序性可中断、可超时相对灵活需要手动解锁需要尝试锁、超时或公平锁等高级语义看起来有四种工具其实底层都指向JMM那两条主线互斥锁保证了“锁内代码段的可见性有序性”volatile和CAS靠“重排序限制立即刷新缓存”保证轻量级的跨线程同步。日常开发时能用volatile解决的问题别全局加锁能用Atomic解决的自增别自己写synchronized块反之临界区逻辑重了就老老实实用锁别跟自旋死磕。7. 从理论到工具的排查链路怎么定位并证明一个并发bug如果光会概念不会排查遇到线上并发故障还是很抓瞎。这里分享一套排查链路是我在项目里反复用过的基本可以覆盖最常见的可见性、死锁和高竞争锁问题。7.1 第一步观察现象抓现场并发出问题特征多为“偶发性”“跟环境强相关”“换个机器就好”。先别急着改代码把现场记录全出现问题的模块、接口、频率、机器配置、JVM版本、GC日志、线程dump。有了这些再定位效率高很多。复现并发bug有一种很有效的方式加大循环次数在多核CPU上跑必要时人为加长临界区执行业务逻辑的时间来扩大竞争窗口。比如前面那个可见性demo如果一直不能复现可以在循环里加一点计算或把JIT关掉-Djava.compilerNONE试试Expansion作用在现场定位的时候很关键。7.2 第二步jstack查线程状态和锁等待jstack是最常用的Java线程dump分析工具。它能打出每个线程的当前状态、栈帧、持有什么锁、在等什么锁。排查死锁时重点留意“Found one Java-level deadlock”这类输出或者在线程状态里看到多个RUNNABLE线程互相等待对方持有的锁。某公司的中间件故障最终就是用jstack抓到两个线程互相持有对方的锁才破案的。除了死锁也要习惯看线程状态分布大量线程处于BLOCKED说明锁竞争激烈。大量线程处于WAITING或TIMED_WAITING可能是在等某个资源过久。线程长期RUNNABLE但一直没进展有可能是活锁或某个死循环空转。用命令生成线程dumpjstack pid thread_dump.txt。如果环境只允许用jconsole也可以从jconsole的线程页签里直接“检测死锁”它会自动帮你列出死锁关系对新手更友好。7.3 第三步JFR和JITWatch深挖热点与编译行为JFRJava Flight Recorder是Oracle JDK里的商业特性现在OpenJDK也逐步开放了部分能力。它可以采集锁竞争事件、CPU热点、存活对象分布、JIT编译情况。启动时加-XX:StartFlightRecording或者运行时用jcmd动态开启采样数据比jstack更宏观适合排查“明明感觉锁很忙却看不出哪个线程卡住”的问题。JITWatch是个更适合分析JIT编译行为的工具。它能展示某个方法被JIT编译时的内联、循环展开、逃逸分析等信息。为什么专门提它因为很多“诡异”的并发现象其实是JIT优化出来的效果比如某个字段没被读直接被优化掉了或循环被重排序了。用JITWatch看生成后的编译产物能直观看到你写的那段代码在机器码层面变成了什么。我遇到过一例某模块的可见性bug在-Xint模式下怎么都复现不了一到正常模式下就偶尔出一次。最后用JITWatch盯着看发现某段循环被优化得极其激进几乎不重新加载共享变量才印证了“热点代码优化后行为跟源码差异很大”的判断。这个问题现在多亏工具能看见汇编了纯靠肉眼猜的话真会怀疑人生。7.4 第四步改动并验证别靠猜来修定位到问题后修改一定要带着“我要证明这个改动解决了问题”的目标来验证。改前复现出问题改后再跑同样的用例同一台环境、同样的循环规模、同样的随机种子这样才有说服力。举例说你怀疑某个字段缺volatile先复现加上volatile后再跑固定次数确实不再复现了才能把结论坐实。如果你顺手把别的逻辑也改了那就说不清是哪个改动起了作用。并发bug的修复尤其忌讳“修完顺便重构了一下”排查范围会瞬间爆炸。还有一个小经验在排查可疑代码前把打印日志的语句全部检查一遍防止日志自身的字符串操作代价影响到线程调度时序。我之前就踩过这种坑本意是加日志调试结果日志反而改变了竞争的窗口让问题忽隐忽现。8. 深入并发代码的三个进阶方向从“会用”到“能设计”走到这一步JMM的基础知识和排查手段都有了但要在并发这条路上继续深入还需要补几块拼图。这里按实用度排个序方便你规划学习路径。8.1 并发容器和AQS是绕不开的样板java.util.concurrent包里的类是好教材。ConcurrentHashMap为什么读操作普遍不需要加锁分割粒度和volatile数组引用怎么配合CopyOnWriteArrayList为什么适合读多写少这些问题的答案都能用JMM的可见性、有序性、原子性三条主线去推导。AQSAbstractQueuedSynchronizer是ReentrantLock、Semaphore、CountDownLatch等类的底层骨架。它维护一个volatile int state来表示同步状态通过CAS更新state内部是一个CLH变体队列管理等待线程。理解了AQS你再看各种并发工具会发现它们都只是不同策略的state转移函数而已底层对线程的阻塞唤醒机制同根同源。阅读AQS源码时集中精力看acquire和release两个方法就够了不需要背整条链表细节重点是理解线程在什么条件下入队、什么条件下唤醒。8.2 锁粒度设计的度量临界区大小和吞吐建模锁粒度不是越细越好。线程池里有N个线程同时抢一个细粒度锁可能大量线程在自旋等待CPU空转但锁太粗持锁时间太长其他线程干等。取舍标准和数据库的事务隔离类似需要先知道临界区操作的计算量级、并发线程数、操作频率再决定要不要锁分段、能不能用读写锁分离。我做过一个模拟场景Redis客户端批量写入redis客户端本身有连接池业务代码又包了一个同步块保护一个本地状态列表。并发量从每秒几百升到几千时这个完全不需要互斥的逻辑导致延迟暴涨。后来分析发现锁本身没问题问题是同步块把不相关的网络IO包括进去了改成只对状态更新加锁性能立刻上来了。锁粒度设计一个很实用的原则同步范围尽量只覆盖共享变量的读写别把方法里无关耗时逻辑圈进去。8.3 用压测和故障注入验证并发正确性并发正确性不能只靠“看一眼代码没问题”。有条件的项目可以引入故障注入工具比如在线程调度过程中随机sleep或随机挂起一段时间来扩大竞争窗口也可以借助ThreadLocal的使用规范和依赖检查工具扫一遍是否存在共享可变状态被随意修改。再配合压测工具观察不同并发度下吞吐量、延迟分布、锁等待时间变化。如果并发度上升后延迟剧烈恶化大概率是锁竞争或热点资源问题如果并发度上升后功能偶发异常大概率是可见性或原子性问题。这两类方向的排查路径完全不同先用数据区分开能少走很多弯路。9. 一些值得留在脑子里的经验面试、面试题和日常代码习惯最后这部分不写总结了只聊几个我个人的体会和习惯算是给同样在并发路上摸爬滚打的人的一些私货。面试场合里JMM问得深其实是在考察你有没有读过官方的JSR-133文档。如果面试官问你“volatile和synchronized区别”漂亮解答是分可见性、原子性、有序性三条说如果问“为什么要有JMM”光答“为了屏蔽硬件差异”还差点最好补上“她规定了happens-before规则和安全发布语义给程序员一个统一模型”。能说到这一层明显就是有自己的理解了。日常代码里我养成了一个习惯每个共享可变字段必须能快速回答三个问题——它被哪些线程触碰它和别的字段之间的更新顺序有没有业务约束如果没有加锁或volatile我会不会读到中间态这三个问题过一遍很多bug在写代码阶段就没了。尤其是字段发布时间点强烈建议所有通过静态方法返回的共享实例都检查一下是不是安全发布。排查并发bug时先确认自己的假设可证伪。我经常看到同事一上来就说“肯定是缓存问题”其实先想清楚“如果真是缓存问题这个必然现象是什么”再设计一个能暴露这个必然现象的实验。按这个思路操作通常比瞎猜快得多。最后说一个比较实用的小技巧给所有的并发测试都固定线程数和循环次数记录通过率。并发问题修复后跑固定的复现用例通过率从90%提升到100%比一句“应该没问题了”有说服力得多。把通过率作为并发修复的“验收指标”你会在团队评审里有话语权。这些细碎的习惯累积起来就是判断一个工程师能不能扛并发故障的关键分水岭。