一条i在十亿次并发调用中悄然丢失更新这不是计算错误而是内存模型在背后设下的陷阱。无数Java开发者把并发问题归结于“锁没加对”却忽略了更深层的真相你看到的代码执行顺序从来都不是CPU真正执行的顺序。Java内存模型Java Memory Model, JMM就是那座连接源码逻辑与硬件乱序执行之间的独木桥。理解它你才能在千核万线程的洪流中准确预测每一个变量的最终归宿。从一条指令的“可见性”说起假设两个线程A和B同时读写同一个共享变量flag。A线程写入flag trueB线程循环等待flag变为true才继续执行。直觉上B迟早会跳出循环。但在无限循环的实测中B可能永远卡死。这不是编译器优化出了bug而是JMM规定线程对共享变量的修改必须先同步到主内存其他线程再从主内存拉取最新值。这个同步过程没有强制时间限制。A线程修改flag后它的值可能只停留在CPU的高速缓存或寄存器里B线程的CPU缓存中依然是旧的false。这种“看不见”而非“不存在”的现象就是可见性问题。它比死锁更隐蔽比竞态更难复现因为每次运行硬件调度都不同。JMM的抽象主内存与工作内存JMM为所有共享变量定义了一套统一的读写规则。它把内存划分为两片疆域所有线程共享的主内存以及每个线程私有的工作内存。工作内存并非真实物理内存它是CPU缓存、写缓冲区、寄存器等硬件的抽象替代品。线程对变量的任何操作都必须先在工作内存中进行副本拷贝再批量刷新回主内存。这意味着即使你是最简单的赋值语句int x a;JVM也会生成load从主内存加载副本、use使用副本值等一系列底层动作。这种设计让Java程序在不同CPU架构上获得一致的并发语义但也带来了巨大的性能代价。所以JVM严格遵循“按需拷贝、延迟刷新”的懒惰策略——只要不发生被迫同步的事件工作内存与主内存永远允许不一致。重排序你以为的顺序是错的比可见性更反直觉的是重排序。为了极致利用流水线编译器和CPU会调整指令执行顺序只要不改变单线程程序的最终结果。例如你写下int a 1; int b 2; int c a b;CPU完全可能先执行b 2再执行a 1因为两条指令互不依赖。在多线程环境下这种重排序就会造成灾难。经典的双重检查锁单例模式如果不加volatile就可能因为instance new Singleton()这行代码的三步操作分配内存、初始化对象、将引用赋值被重排序为“先赋值引用、后初始化对象”导致另一个线程拿到一个半构造的对象。JMM允许这种无害于单线程、却有害于多线程的重排序因为它只约束了“数据依赖性”而锁或volatile才能建立跨线程的“内存屏障”。happens-before规则唯一的定心丸既然重排序如此肆意开发者靠什么推导并发正确性JMM给出了happens-before规则集合。如果操作A happens-before 操作B那么A的所有内存修改在B执行时对B可见且A的操作顺序在B之前。这七个规则里程序员最常用的是程序顺序规则同一线程内代码顺序即happens-before锁规则解锁操作happens-before 后续对同一把锁的加锁volatile规则对一个volatile变量的写操作happens-before 后续对该volatile变量的读传递性。规则的本质是你不需要记住每次内存刷新的具体时机只需要判断自己的代码是否满足这些天然的血缘关系。比如synchronized方法结束后所有修改自动释放给下一个获得同一把锁的线程。这正是JMM对“锁”的语义定义——它不仅是互斥更是内存可见性的交付凭证。volatile轻量级的同步但别神化它volatile是JMM中最矛盾的修饰符。它提供读写的可见性和禁止指令重排序但不提供原子性。一个volatile int count多线程执行count时count的值依然可能错乱因为“读-改-写”三步不是原子的。然而volatile的厉害之处在于内存屏障JVM在volatile写操作前后插入StoreStore、StoreLoad屏障在其他线程的volatile读操作前后插入LoadLoad、LoadStore屏障。这些屏障精确地封锁了重排序边界让该变量仿佛被一道光柱照亮——任何读volatile变量的线程都会立刻看到最近一次写volatile之前的全部共享修改。因此它可以用来做“状态标志位”、发布不可变对象、或配合CAS实现无锁同步。但如果你试图用一堆volatile变量去组合一个不变式比如两个变量的和必须恒为100那注定会失败。synchronized的内存语义管道的两端与volatile的单向可见性不同synchronized提供了双向的内存栅栏。进入synchronized块时JMM会清空当前线程的工作内存强制从主内存重新读取所有变量退出时强制将工作内存中的修改一次性刷新到主内存。这一切等价于加锁动作 读主内存中的最新值解锁动作 写回主内存。所以同一把锁的临界区之间天然形成了happens-before关系。但很多人忽略了锁的“重量”在哪里——它在底层的lock前缀指令和上下文切换开销之间。高并发下锁竞争带来的缓行cache line ping-pong才是性能杀手。优化锁粒度比优化锁本身更重要能缩小临界区就缩小能用读写锁就不互斥能无锁就无锁。CAS与缓存一致性协议现代CPU提供了compare-and-swap原子指令Java的AtomicInteger正是封装了它。CAS操作一个关键前提是“读取-比较-写入”必须在硬件层面不被中断但这还不够——多个CPU核心同时修改同一个变量时缓存一致性协议如MESI会介入。MESI为每个缓存行标记四个状态Modified、Exclusive、Shared、Invalid当某个CPU尝试修改处于Shared状态的行时必须发送无效化消息给所有其他持有该行的核心。这一过程会产生显著的通信延迟也就是所谓的“缓存颠簸”。高并发场景下AtomicInteger的CAS自旋会因为大量失败重试而白耗CPU。基于Java的并发内存模型无锁算法不是魔法它只是把冲突代价从“阻塞—唤醒”转移到了“自旋—重试”。实践中的LongAdder就聪明得多它把单一热点拆成多个cell减少多线程对同一缓存行的竞争。final的隐藏保证不可变对象的最后防线很多人以为final只是防止引用被修改但在JMM中final还有特殊的内存语义构造函数内对final字段的写入与随后任意线程对该对象的引用发布之间必须存在happens-before关系。换句话说final字段的初始化值不会被重排序暴露到对象构造完成之前。这对于发布不可变对象如HashMap中的key、字符串常量至关重要。但请注意final只保证引用本身不可变不保证所引用对象内部的字段不可变。如果你定义一个final ListInteger仍然可以往这个list里添加元素而添加操作若由多个线程执行可见性依然受普通规则约束。不可变对象的真正意义在于一旦构造完成它的状态永远不变因此无需任何同步即可安全发布。高并发场景下的内存模型实战心法回到开头的i问题。最安全的方式当然是原子类或锁但性能敏感的中间件设计中更常见的是单线程写、多线程读的发布模型。比如Netty的EventLoop所有状态变更只在单线程内跑其他线程通过task队列异步提交。此时你不需要复杂的内存屏障因为task队列的入队和出队本身就构建了happens-before链。真正的高手不会在并发代码里写满synchronized而是巧妙地设计数据流让跨线程的每一次交接都正好落在一个内存屏障上。如果你无法避免多线程并发修改多个变量请一定记住要么全用同一个锁包裹要么全部声明为volatile并配合不可变替代方案——混用同步和volatile去保护同一组变量比不用还危险。从JMM到现实压测与工具理论总是干净的现实是肮脏的。JMM的可见性保证是“最坏情况下的最小值”但实际运行中x86平台往往表现出比JMM更强的顺序性因为TSO模型而ARM和PowerPC架构则更接近JMM的弱内存模型。这就意味着在开发机器上跑一万遍都正常的并发代码部署到ARM服务器上可能瞬间暴雷。所以任何高并发组件必须用jcstress做压力测试它的并发测试用例会故意安排不同线程的访问交错并通过Actor注解强制制造竞态场景。jcstress能暴露绝大多数内存可见性问题但它不能证明正确性只能证明在你的测试配置下没有失败。结合hsdis观察JIT生成的汇编指令才是验证内存屏障是否被正确插入的终极手段。结语内存模型是并发编程的底层契约你无法阻止CPU重排序也无法强迫线程及时刷新缓存但你可以选择遵守JMM的规则。规则之内的代码无论跑到什么架构上都安全规则之外的代码哪怕当前跑得飞快也是悬在头顶的达摩克利斯之剑。从今天起每次写下一个共享变量时问自己三个问题它会被多个线程读写吗读写之间有同步措施吗同步措施是否覆盖了所有访问路径如果答案有任何一个“否”JMM的鬼影就会在某个深夜降临。高并发不仅仅是对锁的优化更是对内存模型的敬畏。这份敬畏才是让系统在千万QPS下依然稳如磐石的钥匙。 
长河君 · 2026/8/28 15:55:56 · 阅读 1.2k 基于Java开发的高并发场景内存模型浅析
一条i在十亿次并发调用中悄然丢失更新这不是计算错误而是内存模型在背后设下的陷阱。无数Java开发者把并发问题归结于“锁没加对”却忽略了更深层的真相你看到的代码执行顺序从来都不是CPU真正执行的顺序。Java内存模型Java Memory Model, JMM就是那座连接源码逻辑与硬件乱序执行之间的独木桥。理解它你才能在千核万线程的洪流中准确预测每一个变量的最终归宿。从一条指令的“可见性”说起假设两个线程A和B同时读写同一个共享变量flag。A线程写入flag trueB线程循环等待flag变为true才继续执行。直觉上B迟早会跳出循环。但在无限循环的实测中B可能永远卡死。这不是编译器优化出了bug而是JMM规定线程对共享变量的修改必须先同步到主内存其他线程再从主内存拉取最新值。这个同步过程没有强制时间限制。A线程修改flag后它的值可能只停留在CPU的高速缓存或寄存器里B线程的CPU缓存中依然是旧的false。这种“看不见”而非“不存在”的现象就是可见性问题。它比死锁更隐蔽比竞态更难复现因为每次运行硬件调度都不同。JMM的抽象主内存与工作内存JMM为所有共享变量定义了一套统一的读写规则。它把内存划分为两片疆域所有线程共享的主内存以及每个线程私有的工作内存。工作内存并非真实物理内存它是CPU缓存、写缓冲区、寄存器等硬件的抽象替代品。线程对变量的任何操作都必须先在工作内存中进行副本拷贝再批量刷新回主内存。这意味着即使你是最简单的赋值语句int x a;JVM也会生成load从主内存加载副本、use使用副本值等一系列底层动作。这种设计让Java程序在不同CPU架构上获得一致的并发语义但也带来了巨大的性能代价。所以JVM严格遵循“按需拷贝、延迟刷新”的懒惰策略——只要不发生被迫同步的事件工作内存与主内存永远允许不一致。重排序你以为的顺序是错的比可见性更反直觉的是重排序。为了极致利用流水线编译器和CPU会调整指令执行顺序只要不改变单线程程序的最终结果。例如你写下int a 1; int b 2; int c a b;CPU完全可能先执行b 2再执行a 1因为两条指令互不依赖。在多线程环境下这种重排序就会造成灾难。经典的双重检查锁单例模式如果不加volatile就可能因为instance new Singleton()这行代码的三步操作分配内存、初始化对象、将引用赋值被重排序为“先赋值引用、后初始化对象”导致另一个线程拿到一个半构造的对象。JMM允许这种无害于单线程、却有害于多线程的重排序因为它只约束了“数据依赖性”而锁或volatile才能建立跨线程的“内存屏障”。happens-before规则唯一的定心丸既然重排序如此肆意开发者靠什么推导并发正确性JMM给出了happens-before规则集合。如果操作A happens-before 操作B那么A的所有内存修改在B执行时对B可见且A的操作顺序在B之前。这七个规则里程序员最常用的是程序顺序规则同一线程内代码顺序即happens-before锁规则解锁操作happens-before 后续对同一把锁的加锁volatile规则对一个volatile变量的写操作happens-before 后续对该volatile变量的读传递性。规则的本质是你不需要记住每次内存刷新的具体时机只需要判断自己的代码是否满足这些天然的血缘关系。比如synchronized方法结束后所有修改自动释放给下一个获得同一把锁的线程。这正是JMM对“锁”的语义定义——它不仅是互斥更是内存可见性的交付凭证。volatile轻量级的同步但别神化它volatile是JMM中最矛盾的修饰符。它提供读写的可见性和禁止指令重排序但不提供原子性。一个volatile int count多线程执行count时count的值依然可能错乱因为“读-改-写”三步不是原子的。然而volatile的厉害之处在于内存屏障JVM在volatile写操作前后插入StoreStore、StoreLoad屏障在其他线程的volatile读操作前后插入LoadLoad、LoadStore屏障。这些屏障精确地封锁了重排序边界让该变量仿佛被一道光柱照亮——任何读volatile变量的线程都会立刻看到最近一次写volatile之前的全部共享修改。因此它可以用来做“状态标志位”、发布不可变对象、或配合CAS实现无锁同步。但如果你试图用一堆volatile变量去组合一个不变式比如两个变量的和必须恒为100那注定会失败。synchronized的内存语义管道的两端与volatile的单向可见性不同synchronized提供了双向的内存栅栏。进入synchronized块时JMM会清空当前线程的工作内存强制从主内存重新读取所有变量退出时强制将工作内存中的修改一次性刷新到主内存。这一切等价于加锁动作 读主内存中的最新值解锁动作 写回主内存。所以同一把锁的临界区之间天然形成了happens-before关系。但很多人忽略了锁的“重量”在哪里——它在底层的lock前缀指令和上下文切换开销之间。高并发下锁竞争带来的缓行cache line ping-pong才是性能杀手。优化锁粒度比优化锁本身更重要能缩小临界区就缩小能用读写锁就不互斥能无锁就无锁。CAS与缓存一致性协议现代CPU提供了compare-and-swap原子指令Java的AtomicInteger正是封装了它。CAS操作一个关键前提是“读取-比较-写入”必须在硬件层面不被中断但这还不够——多个CPU核心同时修改同一个变量时缓存一致性协议如MESI会介入。MESI为每个缓存行标记四个状态Modified、Exclusive、Shared、Invalid当某个CPU尝试修改处于Shared状态的行时必须发送无效化消息给所有其他持有该行的核心。这一过程会产生显著的通信延迟也就是所谓的“缓存颠簸”。高并发场景下AtomicInteger的CAS自旋会因为大量失败重试而白耗CPU。基于Java的并发内存模型无锁算法不是魔法它只是把冲突代价从“阻塞—唤醒”转移到了“自旋—重试”。实践中的LongAdder就聪明得多它把单一热点拆成多个cell减少多线程对同一缓存行的竞争。final的隐藏保证不可变对象的最后防线很多人以为final只是防止引用被修改但在JMM中final还有特殊的内存语义构造函数内对final字段的写入与随后任意线程对该对象的引用发布之间必须存在happens-before关系。换句话说final字段的初始化值不会被重排序暴露到对象构造完成之前。这对于发布不可变对象如HashMap中的key、字符串常量至关重要。但请注意final只保证引用本身不可变不保证所引用对象内部的字段不可变。如果你定义一个final ListInteger仍然可以往这个list里添加元素而添加操作若由多个线程执行可见性依然受普通规则约束。不可变对象的真正意义在于一旦构造完成它的状态永远不变因此无需任何同步即可安全发布。高并发场景下的内存模型实战心法回到开头的i问题。最安全的方式当然是原子类或锁但性能敏感的中间件设计中更常见的是单线程写、多线程读的发布模型。比如Netty的EventLoop所有状态变更只在单线程内跑其他线程通过task队列异步提交。此时你不需要复杂的内存屏障因为task队列的入队和出队本身就构建了happens-before链。真正的高手不会在并发代码里写满synchronized而是巧妙地设计数据流让跨线程的每一次交接都正好落在一个内存屏障上。如果你无法避免多线程并发修改多个变量请一定记住要么全用同一个锁包裹要么全部声明为volatile并配合不可变替代方案——混用同步和volatile去保护同一组变量比不用还危险。从JMM到现实压测与工具理论总是干净的现实是肮脏的。JMM的可见性保证是“最坏情况下的最小值”但实际运行中x86平台往往表现出比JMM更强的顺序性因为TSO模型而ARM和PowerPC架构则更接近JMM的弱内存模型。这就意味着在开发机器上跑一万遍都正常的并发代码部署到ARM服务器上可能瞬间暴雷。所以任何高并发组件必须用jcstress做压力测试它的并发测试用例会故意安排不同线程的访问交错并通过Actor注解强制制造竞态场景。jcstress能暴露绝大多数内存可见性问题但它不能证明正确性只能证明在你的测试配置下没有失败。结合hsdis观察JIT生成的汇编指令才是验证内存屏障是否被正确插入的终极手段。结语内存模型是并发编程的底层契约你无法阻止CPU重排序也无法强迫线程及时刷新缓存但你可以选择遵守JMM的规则。规则之内的代码无论跑到什么架构上都安全规则之外的代码哪怕当前跑得飞快也是悬在头顶的达摩克利斯之剑。从今天起每次写下一个共享变量时问自己三个问题它会被多个线程读写吗读写之间有同步措施吗同步措施是否覆盖了所有访问路径如果答案有任何一个“否”JMM的鬼影就会在某个深夜降临。高并发不仅仅是对锁的优化更是对内存模型的敬畏。这份敬畏才是让系统在千万QPS下依然稳如磐石的钥匙。