深入理解 Java CAS 底层原理CPU lock cmpxchg 指令与 ABA 问题解决方案在 Java 高并发编程领域从java.util.concurrent.atomic包下的原子变量到构建锁大厦的基石 AQSAbstractQueuedSynchronizer再到ConcurrentHashMap的分段更新与无锁并发队列其底层几乎全部建立在一套名为 CASCompare-And-Swap比较并交换的无锁原子机制之上。绝大多数开发者在面试或技术交流中都能脱口而出“CAS 就是比较内存中的值是否等于预期值如果是则更新为新值底层调用了Unsafe类”。然而一旦面试官继续追问Unsafe调用的 Native 方法在 JVM 内部是如何落地的在现代多核 CPU 架构下硬件层面凭什么能保证“比较并替换”这两步操作不会被其他核并发打断传说中的 ABA 问题在普通数值累加中似乎人畜无害为什么在基于链表的无锁并发容器中会引发致命的内存崩塌要彻底解开这些谜团我们必须撕开 Java 的封装一路向下穿透到 HotSpot C 源码、x86 汇编指令以及 CPU 缓存一致性协议的最底层。从 Java 源码到 JVM 的内联汇编穿透在现代 JDK包括 Java 21 与 Java 24中虽然推荐通过VarHandle替代直接调用受限的sun.misc.Unsafe但其底层的底层依然收敛到相同的原生原子原语。以AtomicInteger.compareAndSet为例public class AtomicInteger extends Number implements java.io.Serializable { private static final jdk.internal.misc.Unsafe U jdk.internal.misc.Unsafe.getUnsafe(); private static final long VALUE U.objectFieldOffset(AtomicInteger.class, value); private volatile int value; public final boolean compareAndSet(int expectedValue, int newValue) { return U.compareAndSetInt(this, VALUE, expectedValue, newValue); } }深入到 OpenJDK HotSpot 虚拟机的源码位于src/hotspot/os_cpu/linux_x86/atomic_linux_x86.hpp我们会看到compareAndSetInt最终落实到了如下关键的 C 内联汇编代码片段template templatetypename T inline T Atomic::PlatformCmpxchg4::operator()(T exchange_value, T volatile* dest, T compare_value, atomic_memory_order order) const { STATIC_ASSERT(4 sizeof(T)); __asm__ volatile (lock cmpxchgl %1,(%3) : a (exchange_value) : r (exchange_value), a (compare_value), r (dest) : cc, memory); return exchange_value; }关键指令解密cmpxchgl与lock前缀这段汇编的核心在于两个词cmpxchgl指令和它前面的lock前缀。cmpxchgl指令Compare and Exchange它的作用是将%1新值exchange_value与%3目标内存地址dest进行操作。它会隐式读取EAX寄存器中的值即compare_value期望值并与(%3)内存中的实际值进行比较。如果相等硬件将新值写入(%3)内存并将标志寄存器的零标志位ZF置 1如果不相等硬件将内存中的最新实际值写回EAX寄存器并将 ZF 清零。为什么单靠cmpxchgl还不够为什么必须加lockcmpxchgl本身虽然是一条汇编指令但在 CPU 微架构执行层面它包含**“读内存 - ALU 比较 - 写内存”**三个微操作Micro-ops。在多核心Multi-Core SMP架构下核心 A 在执行比较时核心 B 完全可能同时向同一个内存地址写入数据。如果没有硬件级互斥保证这两条并行的微操作依然会发生数据撕裂Data Race。前缀lock是一道绝对的硬件栅栏。硬件底层如何实现lock总线锁与缓存锁在 CPU 物理层面lock前缀经历了从粗暴到精细的架构演进graph TD subgraph Early_Architecture[早起架构: 总线锁 Bus Lock] CPU1[Core 1 执行 lock 指令] --|拉低 LOCK# 信号引脚| Bus[系统总线 System Bus] CPU2[Core 2] -.-|无法访问任何内存| Bus Bus -- Memory[物理内存 RAM] end subgraph Modern_Architecture[现代架构: 缓存锁 Cache Lock MESI] CoreA[Core A] --|命中 L1/L2 缓存行| CacheLine[Cache Line: 状态变为 Modified / Exclusive] CoreB[Core B] --|总线嗅探监听到锁| Wait[等待 Core A 释放该缓存行] end1. 早期总线锁Bus Lock在早期的 x86 处理器中当某个核心执行带lock前缀的指令时处理器会直接在芯片管脚上拉低LOCK#电平信号。这意味着整个系统总线被独占锁定其他 CPU 核心甚至 DMA 控制器在锁释放前连访问其他毫无关系的内存地址都会被挂起。这种方式虽然绝对安全但代价是整个系统的吞吐量瞬间骤降。2. 现代缓存锁Cache Lock 与 MESI 协议现代多核 CPU从奔腾 4 及之后只要操作的数据可以被缓存在处理器的 Cache Line 中通常为 64 字节且没有跨越两个缓存行边界CPU 便不再使用代价高昂的总线锁而是升级为缓存锁Cache Lock利用缓存一致性协议如 MESI 或 MOESICore A 在执行lock cmpxchgl时会将该缓存行的状态修改为 Exclusive独占或 Modified修改。Core A 独占对该缓存行的修改权并通过总线嗅探机制Bus Snooping阻止其他核心同时修改或读取该缓存行。其他核心若试图操作该内存区域必须等待 Core A 完成原子操作并将缓存行状态同步回内存或响应。同时lock前缀在硬件层面天然具备**全内存屏障Full Memory Barrier**的效果禁止指令在它前后发生任何重排序并强制刷新写缓冲区Store Buffer保证了强一致的可见性。ABA 问题的灾难性后果不要以为只是“数值没变”很多同学在面试中谈到 ABA 问题时往往轻描淡写地说“变量一开始是 A被改成了 B又被改回了 ACAS 发现还是 A 就以为没变过其实只是一种误判反正值还是 A能有什么大不了的”如果仅仅是数值计数如从 10 扣减到 5 再充值到 10ABA 或许只是逻辑上不够优雅。但在无锁数据结构Lock-Free Data Structures中ABA 会直接引发野指针、悬挂引用与链表数据静默丢失的毁灭性灾难。经典事故现场Treiber 无锁栈的 ABA 崩塌我们来看一个标准的无锁并发栈实现片段public class ConcurrentStackT { private static class NodeT { T item; NodeT next; Node(T item) { this.item item; } } private final AtomicReferenceNodeT top new AtomicReference(); public void push(T item) { NodeT newHead new Node(item); NodeT oldHead; do { oldHead top.get(); newHead.next oldHead; } while (!top.compareAndSet(oldHead, newHead)); } public T pop() { NodeT oldHead; NodeT newHead; do { oldHead top.get(); if (oldHead null) return null; newHead oldHead.next; // 致命读取点记录了 oldHead 的下一个节点 } while (!top.compareAndSet(oldHead, newHead)); return oldHead.item; } }假设当前栈内元素自顶向下为A - B - C。现在有两个线程并发执行pop()操作线程 1准备出栈它读取到oldHead A并推导得出newHead oldHead.next B。此时线程 1 就在即将执行 CAS 的那一刹那被操作系统线程调度器强行剥夺了 CPU 时间片挂起了。线程 2获得 CPU接连执行出栈操作线程 2 执行pop()成功弹出A线程 2 再次执行pop()成功弹出B此时栈中只剩下C栈顶为C。接着业务逻辑在其他地方又压入了一个新节点碰巧这个新节点复用了之前节点A的内存地址在 C 中为内存池重分配在 Java 中为引用复用但它的next指向了null。此时栈的真实结构变成了A - null。线程 1 终于被唤醒线程 1 恢复执行top.compareAndSet(oldHead, newHead)。它检查当前的栈顶依然是ACAS 判定匹配成功线程 1 欣喜地把栈顶更新为它之前预存的newHead也就是B灾难发生节点B早在第 2 步就已经被线程 2 彻底出栈并废弃了。此时整个栈顶指针瞬间指向了一个已经被孤立的节点B而原本属于栈顶的节点以及后续的真实数据全部从栈链条中断裂丢失这就是无锁链表在遭遇 ABA 时最典型的拓扑结构破坏。工业级解决方案版本戳与版本代际控制消除 ABA 问题的唯一公理是不仅比较对象的值/引用本身还必须核验其流转状态所绑定的单调递增版本号Version Stamp / Epoch。1. JDK 提供的解决方案AtomicStampedReferenceJDK 在java.util.concurrent.atomic中提供了标准实现import java.util.concurrent.atomic.AtomicStampedReference; public class ABASolution { // 初始对象为 A初始版本号为 1 private static final AtomicStampedReferenceString ref new AtomicStampedReference(A, 1); public static void main(String[] args) { int initialStamp ref.getStamp(); String initialRef ref.getReference(); // 线程 1 尝试更新必须同时校验引用与版本号 boolean success ref.compareAndSet( initialRef, // 期望引用 B, // 新引用 initialStamp, // 期望版本号 initialStamp 1 // 新版本号 ); System.out.println(CAS 更新结果: success , 最新版本: ref.getStamp()); } }其内部原理非常优雅它将原本的引用与一个整型int stamp封装成一个不可变的轻量级内部对象PairTprivate static class PairT { final T reference; final int stamp; private Pair(T reference, int stamp) { this.reference reference; this.stamp stamp; } static T PairT of(T reference, int stamp) { return new PairT(reference, stamp); } }在执行compareAndSet时先比较当前Pair的内存指针再比较内部的reference与stamp。即使引用被篡改回原值只要stamp单调递增CAS 就会毫不留情地返回false从而守卫了无锁状态的安全边界。性能反思CAS 自旋风暴与 LongAdder 的破局之道CAS 虽好却并非没有代价。在超高并发争用场景下例如几十个线程同时对一个普通的AtomicLong执行incrementAndGet由于只有一个线程能成功修改其他几十个线程将全部陷入死循环自旋。这会导致CPU 空转飙升自旋消耗了海量 CPU 周期却没有任何有效业务产出。总线风暴Bus Snooping Storm由于大量 CPU 核心在同一时刻对同一块内存缓存行疯狂发起修改与广播失效缓存一致性协议在总线上引发巨大的流量风暴拖垮整个 CPU 互联架构。正是为了化解 CAS 在高争用下的性能崩塌JDK 8 引入了LongAdder其核心思想借鉴了分库分表的“空间换时间”理念——采用分段累加单元Cell 数组当线程检测到在基础值base上发生 CAS 冲突时不再原地盲目死循环而是根据当前线程哈希值分散到不同的Cell槽中分别进行 CAS 累加最终求和时遍历所有Cell与base进行归约汇总。这种将全局冲突拆解为局部冲突的设计才是高并发架构演进的终极方向。结语从 Java 层的原子类到 HotSpot 的lock cmpxchgl再到硬件总线与 MESI 缓存一致性协议CAS 的演进展示了计算机系统跨越软件与硬件协同设计的极致精妙。作为一名合格的后端架构师掌握并发编程绝不能停留在“能背出几个 API”的层面。只有看清指令级的执行细节、理解缓存锁的物理机制、看穿 ABA 背后隐藏的指针陷阱我们才能在高并发、分布式、低延迟的极端战场上写出真正坚不可摧的底层系统。 
长河君 · 2026/10/7 8:27:38 · 阅读 1.2k 深入理解 Java CAS 底层原理：CPU lock cmpxchg 指令与 ABA 问题解决方案
深入理解 Java CAS 底层原理CPU lock cmpxchg 指令与 ABA 问题解决方案在 Java 高并发编程领域从java.util.concurrent.atomic包下的原子变量到构建锁大厦的基石 AQSAbstractQueuedSynchronizer再到ConcurrentHashMap的分段更新与无锁并发队列其底层几乎全部建立在一套名为 CASCompare-And-Swap比较并交换的无锁原子机制之上。绝大多数开发者在面试或技术交流中都能脱口而出“CAS 就是比较内存中的值是否等于预期值如果是则更新为新值底层调用了Unsafe类”。然而一旦面试官继续追问Unsafe调用的 Native 方法在 JVM 内部是如何落地的在现代多核 CPU 架构下硬件层面凭什么能保证“比较并替换”这两步操作不会被其他核并发打断传说中的 ABA 问题在普通数值累加中似乎人畜无害为什么在基于链表的无锁并发容器中会引发致命的内存崩塌要彻底解开这些谜团我们必须撕开 Java 的封装一路向下穿透到 HotSpot C 源码、x86 汇编指令以及 CPU 缓存一致性协议的最底层。从 Java 源码到 JVM 的内联汇编穿透在现代 JDK包括 Java 21 与 Java 24中虽然推荐通过VarHandle替代直接调用受限的sun.misc.Unsafe但其底层的底层依然收敛到相同的原生原子原语。以AtomicInteger.compareAndSet为例public class AtomicInteger extends Number implements java.io.Serializable { private static final jdk.internal.misc.Unsafe U jdk.internal.misc.Unsafe.getUnsafe(); private static final long VALUE U.objectFieldOffset(AtomicInteger.class, value); private volatile int value; public final boolean compareAndSet(int expectedValue, int newValue) { return U.compareAndSetInt(this, VALUE, expectedValue, newValue); } }深入到 OpenJDK HotSpot 虚拟机的源码位于src/hotspot/os_cpu/linux_x86/atomic_linux_x86.hpp我们会看到compareAndSetInt最终落实到了如下关键的 C 内联汇编代码片段template templatetypename T inline T Atomic::PlatformCmpxchg4::operator()(T exchange_value, T volatile* dest, T compare_value, atomic_memory_order order) const { STATIC_ASSERT(4 sizeof(T)); __asm__ volatile (lock cmpxchgl %1,(%3) : a (exchange_value) : r (exchange_value), a (compare_value), r (dest) : cc, memory); return exchange_value; }关键指令解密cmpxchgl与lock前缀这段汇编的核心在于两个词cmpxchgl指令和它前面的lock前缀。cmpxchgl指令Compare and Exchange它的作用是将%1新值exchange_value与%3目标内存地址dest进行操作。它会隐式读取EAX寄存器中的值即compare_value期望值并与(%3)内存中的实际值进行比较。如果相等硬件将新值写入(%3)内存并将标志寄存器的零标志位ZF置 1如果不相等硬件将内存中的最新实际值写回EAX寄存器并将 ZF 清零。为什么单靠cmpxchgl还不够为什么必须加lockcmpxchgl本身虽然是一条汇编指令但在 CPU 微架构执行层面它包含**“读内存 - ALU 比较 - 写内存”**三个微操作Micro-ops。在多核心Multi-Core SMP架构下核心 A 在执行比较时核心 B 完全可能同时向同一个内存地址写入数据。如果没有硬件级互斥保证这两条并行的微操作依然会发生数据撕裂Data Race。前缀lock是一道绝对的硬件栅栏。硬件底层如何实现lock总线锁与缓存锁在 CPU 物理层面lock前缀经历了从粗暴到精细的架构演进graph TD subgraph Early_Architecture[早起架构: 总线锁 Bus Lock] CPU1[Core 1 执行 lock 指令] --|拉低 LOCK# 信号引脚| Bus[系统总线 System Bus] CPU2[Core 2] -.-|无法访问任何内存| Bus Bus -- Memory[物理内存 RAM] end subgraph Modern_Architecture[现代架构: 缓存锁 Cache Lock MESI] CoreA[Core A] --|命中 L1/L2 缓存行| CacheLine[Cache Line: 状态变为 Modified / Exclusive] CoreB[Core B] --|总线嗅探监听到锁| Wait[等待 Core A 释放该缓存行] end1. 早期总线锁Bus Lock在早期的 x86 处理器中当某个核心执行带lock前缀的指令时处理器会直接在芯片管脚上拉低LOCK#电平信号。这意味着整个系统总线被独占锁定其他 CPU 核心甚至 DMA 控制器在锁释放前连访问其他毫无关系的内存地址都会被挂起。这种方式虽然绝对安全但代价是整个系统的吞吐量瞬间骤降。2. 现代缓存锁Cache Lock 与 MESI 协议现代多核 CPU从奔腾 4 及之后只要操作的数据可以被缓存在处理器的 Cache Line 中通常为 64 字节且没有跨越两个缓存行边界CPU 便不再使用代价高昂的总线锁而是升级为缓存锁Cache Lock利用缓存一致性协议如 MESI 或 MOESICore A 在执行lock cmpxchgl时会将该缓存行的状态修改为 Exclusive独占或 Modified修改。Core A 独占对该缓存行的修改权并通过总线嗅探机制Bus Snooping阻止其他核心同时修改或读取该缓存行。其他核心若试图操作该内存区域必须等待 Core A 完成原子操作并将缓存行状态同步回内存或响应。同时lock前缀在硬件层面天然具备**全内存屏障Full Memory Barrier**的效果禁止指令在它前后发生任何重排序并强制刷新写缓冲区Store Buffer保证了强一致的可见性。ABA 问题的灾难性后果不要以为只是“数值没变”很多同学在面试中谈到 ABA 问题时往往轻描淡写地说“变量一开始是 A被改成了 B又被改回了 ACAS 发现还是 A 就以为没变过其实只是一种误判反正值还是 A能有什么大不了的”如果仅仅是数值计数如从 10 扣减到 5 再充值到 10ABA 或许只是逻辑上不够优雅。但在无锁数据结构Lock-Free Data Structures中ABA 会直接引发野指针、悬挂引用与链表数据静默丢失的毁灭性灾难。经典事故现场Treiber 无锁栈的 ABA 崩塌我们来看一个标准的无锁并发栈实现片段public class ConcurrentStackT { private static class NodeT { T item; NodeT next; Node(T item) { this.item item; } } private final AtomicReferenceNodeT top new AtomicReference(); public void push(T item) { NodeT newHead new Node(item); NodeT oldHead; do { oldHead top.get(); newHead.next oldHead; } while (!top.compareAndSet(oldHead, newHead)); } public T pop() { NodeT oldHead; NodeT newHead; do { oldHead top.get(); if (oldHead null) return null; newHead oldHead.next; // 致命读取点记录了 oldHead 的下一个节点 } while (!top.compareAndSet(oldHead, newHead)); return oldHead.item; } }假设当前栈内元素自顶向下为A - B - C。现在有两个线程并发执行pop()操作线程 1准备出栈它读取到oldHead A并推导得出newHead oldHead.next B。此时线程 1 就在即将执行 CAS 的那一刹那被操作系统线程调度器强行剥夺了 CPU 时间片挂起了。线程 2获得 CPU接连执行出栈操作线程 2 执行pop()成功弹出A线程 2 再次执行pop()成功弹出B此时栈中只剩下C栈顶为C。接着业务逻辑在其他地方又压入了一个新节点碰巧这个新节点复用了之前节点A的内存地址在 C 中为内存池重分配在 Java 中为引用复用但它的next指向了null。此时栈的真实结构变成了A - null。线程 1 终于被唤醒线程 1 恢复执行top.compareAndSet(oldHead, newHead)。它检查当前的栈顶依然是ACAS 判定匹配成功线程 1 欣喜地把栈顶更新为它之前预存的newHead也就是B灾难发生节点B早在第 2 步就已经被线程 2 彻底出栈并废弃了。此时整个栈顶指针瞬间指向了一个已经被孤立的节点B而原本属于栈顶的节点以及后续的真实数据全部从栈链条中断裂丢失这就是无锁链表在遭遇 ABA 时最典型的拓扑结构破坏。工业级解决方案版本戳与版本代际控制消除 ABA 问题的唯一公理是不仅比较对象的值/引用本身还必须核验其流转状态所绑定的单调递增版本号Version Stamp / Epoch。1. JDK 提供的解决方案AtomicStampedReferenceJDK 在java.util.concurrent.atomic中提供了标准实现import java.util.concurrent.atomic.AtomicStampedReference; public class ABASolution { // 初始对象为 A初始版本号为 1 private static final AtomicStampedReferenceString ref new AtomicStampedReference(A, 1); public static void main(String[] args) { int initialStamp ref.getStamp(); String initialRef ref.getReference(); // 线程 1 尝试更新必须同时校验引用与版本号 boolean success ref.compareAndSet( initialRef, // 期望引用 B, // 新引用 initialStamp, // 期望版本号 initialStamp 1 // 新版本号 ); System.out.println(CAS 更新结果: success , 最新版本: ref.getStamp()); } }其内部原理非常优雅它将原本的引用与一个整型int stamp封装成一个不可变的轻量级内部对象PairTprivate static class PairT { final T reference; final int stamp; private Pair(T reference, int stamp) { this.reference reference; this.stamp stamp; } static T PairT of(T reference, int stamp) { return new PairT(reference, stamp); } }在执行compareAndSet时先比较当前Pair的内存指针再比较内部的reference与stamp。即使引用被篡改回原值只要stamp单调递增CAS 就会毫不留情地返回false从而守卫了无锁状态的安全边界。性能反思CAS 自旋风暴与 LongAdder 的破局之道CAS 虽好却并非没有代价。在超高并发争用场景下例如几十个线程同时对一个普通的AtomicLong执行incrementAndGet由于只有一个线程能成功修改其他几十个线程将全部陷入死循环自旋。这会导致CPU 空转飙升自旋消耗了海量 CPU 周期却没有任何有效业务产出。总线风暴Bus Snooping Storm由于大量 CPU 核心在同一时刻对同一块内存缓存行疯狂发起修改与广播失效缓存一致性协议在总线上引发巨大的流量风暴拖垮整个 CPU 互联架构。正是为了化解 CAS 在高争用下的性能崩塌JDK 8 引入了LongAdder其核心思想借鉴了分库分表的“空间换时间”理念——采用分段累加单元Cell 数组当线程检测到在基础值base上发生 CAS 冲突时不再原地盲目死循环而是根据当前线程哈希值分散到不同的Cell槽中分别进行 CAS 累加最终求和时遍历所有Cell与base进行归约汇总。这种将全局冲突拆解为局部冲突的设计才是高并发架构演进的终极方向。结语从 Java 层的原子类到 HotSpot 的lock cmpxchgl再到硬件总线与 MESI 缓存一致性协议CAS 的演进展示了计算机系统跨越软件与硬件协同设计的极致精妙。作为一名合格的后端架构师掌握并发编程绝不能停留在“能背出几个 API”的层面。只有看清指令级的执行细节、理解缓存锁的物理机制、看穿 ABA 背后隐藏的指针陷阱我们才能在高并发、分布式、低延迟的极端战场上写出真正坚不可摧的底层系统。