
一篇吃透CAS的ABA问题成因、风险与全套解决方案前言并发编程中我们经常使用CAS(Compare And Swap)实现无锁并发相比重量级synchronized拥有更高吞吐量。很多开发者熟练使用CAS却忽略它经典的ABA漏洞。本文循序渐进讲清楚什么是ABA问题ABA如何产生、会造成什么事故主流解决方案原理 代码示例方案优缺点横向对比一、什么是CAS快速回顾CAS全称比较并交换是乐观锁底层原子操作操作分为两步比较判断内存当前值 预期旧值交换相等则更新为新值不相等直接失败伪代码逻辑if(内存值预期旧值){内存值新值;returntrue;}else{returnfalse;}注意原生CAS只对比数值本身这就是ABA问题的根源二、什么是ABA问题ABA定义线程1读取变量值为A在线程1执行CAS前变量被其他线程修改为B随后又被改回A。线程1执行CAS时发现值依旧是A认为变量没有变动执行更新最终引发数据异常。简单一句话值看上去没变但中间被篡改过ABA完整时序流程图内存变量 VA线程2线程1内存变量 VA线程2线程1线程1阻塞/失去CPU时间片⏸️值变回A肉眼看不出变化CAS判定成功执行覆盖更新⚠️读取V获取值A准备执行CASCAS(A→B)修改成功 VBCAS(B→A)修改成功 VA恢复运行执行CAS(A,新值)三、ABA问题真实场景举例最经典场景并发栈无锁操作单向链表实现栈栈结构A → B → C栈顶 A线程T1准备弹出栈顶A读取头结点A准备执行CAST1暂停线程T2执行出栈弹出A栈变成B→CT2继续把A入栈栈变回A→B→CT1恢复执行CAS发现栈顶依旧是A执行出栈最终链表指针错乱出现内存丢失、循环链表、数据泄露严重bug风险总结原生CAS只校验数值无法识别中间变更历史。简单类型数字场景ABA危害不直观链表、对象引用等基于指针的结构ABA极易引发灾难性BUG。四、ABA问题核心产生原因✅基础版本CAS仅比较数据值不记录变量修改历史变量经历A → B → A最终数值复原线程无法区分【从未修改的A】 vs 【被修改后恢复的A】核心痛点缺少版本标记。五、ABA问题主流解决方案️方案1带版本号的CAS乐观锁版本号机制原理不再只对比数据本身每条数据附带一个自增version版本号每次成功修改变量版本号version version 1CAS条件旧数据 旧版本号 同时匹配才能更新时序图内存 VA,version1线程2线程1内存 VA,version1线程2线程1线程1暂停⏸️当前version3≠1 → CAS失败 ❌获取 VA,version1CAS(A,1→B,2) ✔️ VB,version2CAS(B,2→A,3) ✔️ VA,version3CAS(A,1,新值)Java中对应实现AtomicStampedReference携带戳stamp等价版本号// 初始化 初始值A版本戳stamp1AtomicStampedReferenceStringatomicRefnewAtomicStampedReference(A,1);intoldStampatomicRef.getStamp();StringoldValatomicRef.getReference();// 其他线程修改A→B→Astamp自增为3// CAS值A版本1期望匹配booleansuccessatomicRef.compareAndSet(A,NEW,oldStamp,oldStamp1);// 版本不匹配返回false成功规避ABA方案2AtomicMarkableReference布尔标记存储一个boolean mark标记只能区分「是否被修改过」无法记录修改次数。局限性多次修改后标记会反复翻转不能彻底杜绝ABA适用场景有限。方案3数据库乐观锁 version字段业务开发最常用数据表增加version字段-- 更新时带上版本条件UPDATEuserSETbalancebalance-100,versionversion1WHEREid1ANDversion#{oldVersion};方案4使用重量级锁兜底方案直接抛弃无锁CAS使用synchronized/ReentrantLock同一时间只允许一个线程操作从根源杜绝并发竞争。缺点并发性能下降失去无锁优势。方案5使用GC不变对象不推荐每次修改新建对象不复用旧对象引用成本极高极少使用。六、方案优劣横向对比方案能否彻底解决ABA性能适用场景AtomicStampedReference版本戳✅ 完全解决高Java内存无锁并发AtomicMarkableReference❌ 不完全解决高只关心是否改动不关心次数数据库version乐观锁✅ 完全解决中等数据库业务并发更新synchronized 互斥锁✅ 完全解决较低简单并发追求稳定不追求极致吞吐七、常见误区澄清⚠️AtomicInteger / AtomicLong 会遇到ABA吗会基础原子类只有数值CAS没有版本戳。但普通数值加减场景ABA很难触发严重故障链表、队列无锁实现必须规避。只要用CAS就一定要处理ABA不是。如果业务允许「中间被修改又复原」这种场景可以不用处理。但开发通用无锁数据结构队列、栈必须防范。stamp版本号会溢出吗long型版本戳溢出周期极长工程上基本不用考虑溢出问题。八、总结ABA本质变量先A→B→A原生CAS只对比数值无法感知中间变更最大风险链表、无锁队列等基于引用操作的数据结构标准根治方案增加自增版本号使用带版本校验的CASJava优先使用AtomicStampedReference数据库增加version乐观锁简单并发场景也可以直接使用互斥锁规避并发竞争。日常业务代码很少手写无锁链表ABA问题遇到概率不高但学习并发、阅读JDK源码Concurrent相关容器必须理解这个经典并发缺陷。