Java CAS机制深度解析：原理、应用与ABA问题实战

我写并发代码有五六年了一直觉得CAS是个很神奇的东西——明明只是一个“比较再交换”的简单动作却撑起了JUC半边天。无论是AtomicInteger、LongAdder还是面试必考的AQS底层都离不开它。很多新手学到这里记了一堆“CAS是无锁编程”“CAS是乐观锁”的概念可真要问他“CAS到底怎么保证原子性”“ABA问题怎么解”又答不上来。这篇文章我就结合源码、字节码和实际项目踩坑经历把Java中的CAS机制彻底讲透顺便说说面试八股里那些高频追问到底想考什么。这篇文章适合正在准备Java面试的人也适合已经在写并发代码但总觉得底层缺一块的开发者。我不打算只讲结论会把CAS的硬件基础、Unsafe实现、JUC里的典型应用、三大经典陷阱以及实战调优经验全部串起来。看完之后你不仅能应付“CAS底层原理”“ABA问题”“CAS和synchronized区别”这类问题还能在真正的并发项目里用对CAS。1. CAS机制核心原理拆解1.1 CAS的三个操作数与内存模型CAS全称是Compare And Swap翻译过来就是“比较并交换”。它做的事情非常简单先读一个内存位置的值V再拿它和期望值E比较如果相等就把新值N写进去否则什么都不做。整个过程中V、E、N就是CAS的三个操作数。这个模型对应到Java代码里通常是这样用的boolean compareAndSet(int expect, int update)调用方把“我期望当前值是多少”传进去如果实际值真和期望值一样就更新为目标值并返回true否则返回false。这里的关键是“比较”和“交换”这两个动作必须是原子的不能拆开。为什么不能拆开因为如果在比较结束后、交换开始前另一个线程把这个值改了那这次操作就失真了。理解CAS的最好方式是把它想成“乐观锁”的极致形态。悲观锁是“我先锁住资源谁也别动”乐观锁则是“我默认没人跟我抢先试着改一下改的过程中发现冲突了再重试”。CAS就是一种硬件级别的乐观锁原语它不是靠加锁来互斥而是靠一条CPU指令来保证比较和交换的整体性。内存模型这块也要说清楚。CAS操作必然涉及主内存和线程工作内存的交互。虽然我们平时用AtomicInteger的时候感觉不到但在底层CAS是通过CPU缓存和主内存之间的缓存一致性协议来协调的。线程A修改了某个值线程B要能立刻看到这个可见性由volatile语义来保障。所以你会发现AtomicInteger内部实际上是把value声明成了volatileCAS就是在这个volatile变量上做比较交换。没有volatile的可见性CAS即使原子地改了值其他线程也看不到。1.2 硬件层面如何保证原子性Java层面只是调用了本地方法真正干活的是一系列CPU指令。以x86平台为例核心指令是cmpxchg也就是“compare and exchange”。这条指令接收一个内存地址、一个期望寄存器值、一个新值寄存器值CPU会在指令执行期间锁定总线或者锁缓存行保证比较和交换的原子性。早期的CPU是直接锁总线代价比较大因为锁住总线意味着其他CPU都无法访问内存。后来优化成锁缓存行也就是MESI缓存一致性协议参与下的cache line lock只有当前缓存行被标记为Modified状态时其他核心才无法修改这段数据。这种优化让CAS在大部分场景下都能跑得很快。需要注意的是虽然命令是原子的但“读-比较-写”这一整套逻辑在Java代码里往往表现为一个循环。比如AtomicInteger的incrementAndGet实际执行的是“死循环里反复调用compareAndSet直到成功为止”。因此CAS虽然本身是原子操作但围绕它构建的算法往往是“乐观重试”模式这就带来了后面要讲的自旋开销问题。这里还有一个很实际的概念CAS不是“完全没有锁”它只是“没有线程阻塞”。底层硬件确实用了总线锁或缓存锁只是这种锁的粒度极小、持有时间极短宏观上感知不到线程被挂起唤醒。理解了这一点你就能明白为什么CAS在高并发下可能比synchronized更高效也可能更差——因为自旋会让CPU空转。1.3 Java中的CAS实现Unsafe类与Atomic原子类Java的CAS魔法藏在sun.misc.Unsafe里面。这个类虽然名字叫“不安全”但并发框架到处都用它。核心方法就这几个public final native boolean compareAndSwapInt(Object o, long offset, int expected, int x); public final native boolean compareAndSwapLong(Object o, long offset, long expected, long x); public final native boolean compareAndSwapObject(Object o, long offset, Object expected, Object x);注意这几个方法的参数第一个是对象本身第二个是字段的内存偏移量第三个是期望值第四个是目标值。为什么要传对象和偏移量因为CAS最终要在内存层面操作需要定位到那个字段的准确内存位置。这种写法对普通开发者来说很不友好所以JUC包在Unsafe之上封装了各种Atomic原子类把offset计算都隐藏了。我们平时用得最多的AtomicInteger本质上就是一个封装了volatile int值Unsafe CAS逻辑的类。它的内部有这样一段代码// setup to use Unsafe.compareAndSwapInt for updates private static final Unsafe unsafe Unsafe.getUnsafe(); private static final long valueOffset; static { try { valueOffset unsafe.objectFieldOffset (AtomicInteger.class.getDeclaredField(value)); } catch (Exception ex) { throw new Error(ex); } } private volatile int value;静态代码块里通过反射拿到value字段的偏移量之后CAS操作就直接在该偏移量上做。这也解释了为什么AtomicInteger的性能比普通加锁操作高没有线程上下文切换只有CPU指令级的自旋比较。除了AtomicInteger还有AtomicLong、AtomicReference、AtomicBoolean它们原理一致只是操作的数据类型不同。AtomicReference在处理对象引用的时候特别有用但同时也更容易踩ABA的坑。至于更高级的LongAdder和Striped64它们的核心依然离不开CAS只是把竞争分散到了多个cell上这个概念后面再展开。2. CAS的典型应用场景与代码实战2.1 AtomicInteger的incrementAndGet源码走读很多人在面试时能把AtomicInteger的用法背出来但源码里到底怎么自旋的可能没细看。我先把核心方法贴出来public final int incrementAndGet() { for (;;) { int current get(); int next current 1; if (compareAndSet(current, next)) return next; } }这个循环就是典型的“自旋CAS”。每次先读当前值然后计算目标值接着尝试CAS。如果CAS失败说明在读取和尝试更新之间其他线程已经把值改了于是循环回到起点重新读取最新值再试一次。整个过程不需要锁线程始终在用户态运行不会被操作系统挂起。从实际性能角度看这个设计对低并发场景特别友好。比如一个计数器每秒只有几百次更新几乎每次CAS都能一次成功性能比synchronized高了一个数量级。但如果是超高并发场景比如上千个线程同时往一个AtomicInteger上累加CAS就会频繁失败每个线程都在循环里空转CPU占用率直线上升。这个时候AtomicInteger反而不如LongAdder。顺带说一句incrementAndGet和getAndIncrement的差别只在于返回值顺序前者返回自增后的新值后者返回自增前的旧值。实现逻辑几乎一样只是返回值不同。这个细节也可能出现在面试题里注意别混淆。2.2 自旋锁的手写实现理解CAS最好的方式是自己写一个自旋锁。虽然真实项目里很少让你手写但这个练习能让你彻底搞清楚“CAS实现锁”到底是怎么回事。下面是一个最简版本public class SpinLock { private final AtomicReferenceThread owner new AtomicReference(); public void lock() { Thread current Thread.currentThread(); // 如果owner从null变成current说明抢锁成功 while (!owner.compareAndSet(null, current)) { // 自旋等待可以加Thread.yield()让出CPU } } public void unlock() { Thread current Thread.currentThread(); // 只有持有锁的线程才能解锁 owner.compareAndSet(current, null); } }这段代码里锁状态就是owner引用是否为null。lock时尝试把owner从null改为当前线程成功就代表获得锁失败就继续自旋。unlock时把owner从当前线程改回null这里用compareAndSet可以避免其他线程错误释放锁。整个锁只有几十行代码但功能上确实实现了互斥。不过我在实际测试中发现自旋锁有个很大的问题如果持有锁的线程被阻塞了比如在锁里面做了一次远程调用那么其他线程会在循环里疯狂空转把CPU资源白白吃光。所以自旋锁只适合临界区非常小、执行时间极短、线程竞争不激烈的场景。JUC里面的AbstractQueuedSynchronizer在获取锁失败后也不是无限自旋而是先自旋几次再进入等待队列就是这种思路。2.3 CAS在AQS队列同步器中的角色AQS是Java并发框架的基石ReentrantLock、Semaphore、CountDownLatch都是基于它实现的。AQS里有一个volatile int state字段表示同步状态还有一个双向队列用来存放等待线程。CAS在AQS里的作用就是原子地修改state。以ReentrantLock的加锁为例核心操作是先尝试用CAS把state从0改为1。如果成功当前线程就获得了锁如果失败说明锁被占用线程进入队列等待。改state的方式就是CAS比如protected final boolean compareAndSetState(int expect, int update) { return unsafe.compareAndSwapInt(this, stateOffset, expect, update); }这里的stateOffset也是通过反射提前计算好的。AQS的设计精妙之处在于它把“直接CAS抢锁”和“排队阻塞唤醒”结合在了一起线程先尝试两次CAS抢不到再排队。这样既保留了CAS的高吞吐又避免了长时间自旋消耗CPU。你在面试里可以说AQS就是“CASCLH队列”的经典组合。CLH队列是一种基于链表节点的等待队列每个节点保存着当前线程和等待状态。CAS保证节点状态切换的原子性队列保证等待线程的有序性两者配合起来就是整个JUC同步器家族的底层骨架。理解了AQS里CAS的使用位置很多面试题都能迎刃而解。3. CAS的三大经典陷阱ABA、自旋开销、只能单变量3.1 ABA问题复现与AtomicStampedReference解决CAS最出名的坑就是ABA问题。它的发生条件非常隐蔽线程T1读到当前值是A刚要CAS更新时被打断线程T2把值从A改成B然后又从B改回A这时T1恢复执行发现值还是A于是CAS成功。但问题是值虽然变回了A中间却经历了一段“被修改过”的历程某些依赖历史状态的场景就会出错。举个业务例子。假设你用AtomicReference维护一个“账户余额”线程A准备把余额从100元扣到50元。它先读到余额是100这时线程B给账户充了50元变成150然后又消费退回50元最终余额还是100。线程A醒来后发现余额还是100就执行扣款余额变成50。但事实上账户中间经历过一次充值又退款业务上可能需要重新审核。这个例子有点牵强但足以说明ABA的危害在于“值相等不代表状态等价”。解决ABA问题的标准方案是加版本号。Java里提供了AtomicStampedReference和AtomicMarkableReference。前者可以存“引用版本戳”后者可以存“引用布尔标记”。用版本号或标记来区分“值相同但版本不同”的情况。示例代码如下AtomicStampedReferenceString ref new AtomicStampedReference(A, 0); // 每次更新时需要同时检查引用和版本戳 boolean success ref.compareAndSet(A, B, 0, 1);注意这里的compareAndSet有四个参数期望引用、新引用、期望版本、新版本。只要中间发生过任何修改版本戳就会改变即使引用值回到“A”版本戳也不会是0所以CAS会失败。这就能完美规避ABA问题。不过我实际工作中用AtomicStampedReference的概率并不高因为很多场景下ABA根本无伤大雅。比如统计访问次数只要最终计数是准的中间跳变几次无所谓。做技术选型时先判断业务是否关注中间状态别为了消灭ABA而过度设计。3.2 自旋竞争激烈的性能瓶颈与LongAdder优化思路CAS虽然避免了线程切换但自旋是要消耗CPU的。竞争越激烈自旋次数越多线程一直在for循环里打转宏观表现就是CPU占用飙高、吞吐量下降。为什么LongAdder能优化这个问题因为它把单一热点拆成了多个热点。LongAdder的内部设计是Striped64它维护一个base值和一个Cell数组。当竞争不激烈时线程直接CAS更新base当发现CAS失败次数多了就会把线程通过hash分散到不同的Cell槽位每个线程只更新自己槽位里的值。最后的sum操作把base和所有Cell值加起来。这样多个线程不会都去抢同一个内存地址CAS失败率大大降低。举个例子之前有次压测我用AtomicInteger作为统计数据采集器的计数器模拟500个线程并发累加结果吞吐量只有二十几万一秒CPU还烧到90%。后来换成LongAdder同样的场景吞吐量直接翻了两倍CPU降到60%左右。这个优化点的核心思想就是“化整为零”降低共享变量的写冲突。不过LongAdder也有缺点。因为计数被分散到多个槽位它在sum()的时候不是精准快照也就是说如果你需要保证“累加结果在某一瞬间绝对一致”LongAdder不适合。它适合“最终一致”的统计场景比如QPS计数器、日志埋点统计。而如果你需要不断读取当前精确值来做判断还是老老实实用AtomicInteger。3.3 只能保证单个变量的原子性AtomicReference与可变对象组合问题CAS还有一个隐形的限制——它能保证的是“单个变量”的原子操作。如果你要同时原子地更新两个变量比如“用户积分”和“积分等级”CAS就无能为力。虽然AtomicReference可以包装一个自定义对象把两个字段放进对象里然后原子替换整个引用但这要求每次更新都创建一个新对象频繁GC不说代码也变得很别扭。更麻烦的是如果对象内部字段是可变的比如List你在拿到引用后对List进行增删其他线程可能同时也在操作这个List这时CAS只能保证引用本身的原子替换保证不了List内部的线程安全。这里要特别提醒AtomicReference的CAS比较的是“引用地址”不是对象内容。两个对象内容完全一样但只要不是同一个地址CAS就会失败。所以用AtomicReference做“值比较”时必须小心最好配合不可变对象使用或者在更新时重新构建一个新对象。如果要真正实现“多字段一致更新”有几个方案一是用锁简单直接二是用AtomicReference包装一个不可变的“状态快照对象”每次更新都创建新对象三是用LongAdder等特殊结构的类来分散更新。最忌讳的就是拿多个AtomicXXX变量做组合操作比如先更新一个再更新另一个中间一旦出问题两个变量的值就对不上了。4. 面试八股与高频追问CAS相关题点拆解4.1 面试官视角的连环追问清单CAS是Java并发面试的必考点面试官很少直接问“CAS是什么”他们通常采用连环追问的方式比如介绍一下CAS的原理CAS是怎么实现原子性的CAS和synchronized的区别是什么CAS会带来什么问题ABA是什么怎么解决ABA问题AtomicStampedReference的原理CAS在JUC里有哪些应用为什么AtomicInteger在高并发下性能不好LongAdder相比AtomicInteger做了哪些优化volatile和CAS的关系AQS和CAS是什么关系这些问题环环相扣从基础概念到底层原理再到性能优化覆盖了整个Java并发核心。面试官其实想考察的不仅仅是你会不会背概念而是你有没有真正理解“无锁并发”的底层逻辑和适用边界。哪怕答不出来全部能沿着某一条线深入下去也会加分。我见过很多候选人在“CAS和synchronized区别”这里翻车。他们脱口而出“CAS无锁、synchronized有锁”但实际上CAS底层也有缓存锁synchronized在锁升级后也可能用CAS来抢偏向锁两者不是完全对立的。更好的答案是CAS是一种乐观同步机制synchronized是一种悲观同步机制CAS面向的是细粒度、短临界区、低竞争场景synchronized经过锁升级优化后在不同竞争程度下都有较好表现。4.2 典型回答模板与避坑要点我整理一个比较稳妥的回答思路你可以在面试里参考“CAS的全称是Compare And Swap它包含三个操作数内存位置V、期望值E、新值N。只有V的实际值等于E时才会把N写入V否则什么都不做。这三个步骤在硬件层面通过cmpxchg指令保证原子性。Java里通过Unsafe类的compareAndSwapInt等方法暴露了这个能力JUC的原子类再封装一层给开发者提供了便捷的CAS操作。”“CAS的使用模式通常是自旋循环比如AtomicInteger的incrementAndGet就是for循环里不断尝试compareAndSet直到成功。CAS的好处是减少了线程阻塞和上下文切换坏处是ABA问题、自旋CPU浪费、只能保证单个变量的原子性。其中ABA可以用AtomicStampedReference增加版本号来解决自旋问题可以用LongAdder对热点进行拆分多变量一致性问题可以引入锁或用不可变对象引用替换。”这样回答既完整又清晰。注意几个容易踩的坑第一不要说“CAS不使用锁”要说是“硬件层面的原子操作没有线程阻塞”。第二不要说“CAS永远比synchronized快”实战中竞争激烈时CAS可能更差。第三不要把ABA问题解释成“线程安全”问题ABA本质是“逻辑状态被覆盖”的问题而不仅仅是“值被覆盖”。4.3 CAS与synchronized、volatile的关系和选型这三者经常被混在一起问其实分工完全不同。volatile解决的是“可见性”和“禁止指令重排序”不保证原子性。所以在多线程环境下volatile不能替代CAS实现类似i这样的操作。CAS解决的是“单个变量的原子更新”它本身依赖volatile的可见性来获取最新值。synchronized解决的则是“多行代码的互斥执行”它能保证原子性、可见性和有序性但代价是可能引起线程阻塞。在我实际的选型思路里优先从这三个维度判断如果只是标志位、状态开关用volatile如果是单一变量的计数、累加、比较更新用CAS原子类如果是复合操作、多变量联动、需要锁的语义用synchronized或ReentrantLock。举一个我之前做过的状态机例子。订单状态有PENDING、PAID、SHIPPED、COMPLETED每个状态只能按顺序流转。我用一个AtomicReference 加上一个状态机校验方法每次更新前先校验当前状态是否合法然后CAS替换。这个方案省去了加锁性能很好。但要是同样的状态流转里需要同时更新订单金额、积分、库存等多个字段那CAS就不好使了还是老老实实加锁。5. 实操排查与性能调优经验5.1 从JIT角度看CAS伪共享Contended很多人在写高并发代码时容易忽略一个性能杀手伪共享。简单说CPU加载数据是按缓存行来的一个缓存行通常是64字节。如果两个变量被分配在同一个缓存行里即使它们之间没有逻辑关系其中一个变量被修改时另一个变量的缓存也会失效导致其他线程被迫重新加载。CAS操作特别容易受到伪共享影响因为CAS会反复触发缓存行的写操作。如果你有两个AtomicLong一个记录请求数一个记录成功数它们很可能紧挨着存放在内存里。线程A疯狂更新请求数线程B疯狂更新成功数两个线程虽然在逻辑上互不干扰但物理上它们共享同一个缓存行于是互相拖累。JVM提供了一个注解sun.misc.Contended可以给字段做缓存行填充让这个字段独占缓存行。JDK 8的LongAdder内部Cell数组就用了这个注解。我自己在遇到类似场景时也会用这个注解来做优化。但要注意Contended在普通API代码里默认是无效的需要加JVM参数-XX:-RestrictContended才能生效而且打开后可能会浪费内存要权衡使用。5.2 实际项目中的CAS使用场景复盘计数器、状态机、锁我在项目中用CAS的场景主要有三类。第一类是计数器。比如网关统计接口调用量、监控系统统计埋点数据用AtomicLong或LongAdder非常合适。我已经把LongAdder作为默认的计数类因为它兼顾了低竞争的简洁性和高竞争的扩展性。但要注意LongAdder的sum返回值不是强一致快照所以一旦对应到财务、订单这类需要精确值的场景就要用AtomicLong。第二类是状态机。许多业务实体的状态流转可以用AtomicReference维护。比如工单状态、流程节点状态。每次操作前先CAS判断当前状态是不是期望的如果是就替换成下一状态。这种方式天然避免了重复提交也比加锁轻量。但前提是状态流转路径不能太复杂否则校验逻辑会变得难以维护。第三类是自旋锁和轻量级锁。某些框架里为了尽量减少线程切换在临界区极短的地方使用自旋锁。我在写一个本地缓存刷新的场景时用AtomicBoolean实现过一个“单飞”逻辑多个线程同时发现缓存过期只有一个线程能通过CAS把状态从false改为true其余线程直接返回旧值。这样保证只有一个线程去重建缓存其他线程不阻塞效果很好。5.3 常见错误与排查技巧我在帮助团队排查并发问题时发现CAS导致的问题主要有几个特征程序偶尔出现错误数据、CPU占用高但无明显死锁、问题只在高峰期出现。最容易犯的错误是把CAS当成“万能原子操作”。比如有人在代码里写了这样一段if (atomic.get() 0) { atomic.compareAndSet(0, 1); }这种“先get再CAS”的组合不是原子的。两个线程可能同时读到0然后先后CAS成功。正确做法是直接CAS用返回值判断是否成功不要让get先做判断。这是“检查后执行”的竞态条件经典问题。排查技巧方面先说CPU飙高。如果线上多个线程在CAS循环里自旋jstack会看到大量线程处于RUNNABLE状态并且堆栈停留在compareAndSet上。这时优先排查共享变量是否被多个线程高频访问竞争是否过度集中。如果竞争集中在单一变量考虑用LongAdder或分段结构。再说数据正确性。如果用了AtomicReference但业务状态偶尔错乱优先怀疑ABA问题。可以临时打日志记录每次CAS前后的值和版本或者把AtomicReference换成AtomicStampedReference试一下看问题是否消失。我遇到过因为ABA导致缓存更新丢失的案例排查了很久才发现是两个线程一个先更新再回滚另一个以为状态没变继续走完了整个流程。最后提醒一个新手常犯的错误AtomicInteger的compareAndSet并不等于“如果当前值等于x就执行某个动作”。CAS只负责原子性的“比较-替换”不负责你替换之外的其他逻辑。如果你在CAS成功后还要操作其他共享变量那不是原子操作。要么把所有共享变量封装到不可变对象里一次替换要么老老实实加锁。结尾我个人这几年的体会是CAS不是银弹但它是理解并发本质的一把钥匙。你越深入它越能体会到“无锁”并不是真的无锁而是把锁的粒度缩小到了CPU指令级别。面试问CAS表面上考的是机制实际考的是你对并发边界条件的敏感性。最后再分享一个小技巧当你写任何CAS相关代码时先问自己三个问题——这个操作需要保证原子性吗失败重试的开销能接受吗如果值连续变化多次后回到原值业务上会有影响吗把这三个问题想清楚你就能在绝大多数场景下做出正确的选择。