CAS是JVM借助CPU原子指令实现的乐观无锁同步机制,Java通过Unsafe类方法封装并由Atomic*类(如AtomicInteger)间接使用,其核心是“比较并交换”值,失败则重试。

什么是CAS,它在Java里靠什么实现
CAS(Compare-And-Swap)不是Java语言层的语法,而是JVM底层借助CPU提供的原子指令(如x86的cmpxchg)实现的无锁同步机制。Java中真正暴露给开发者的是Unsafe.compareAndSwapInt这类方法,但日常几乎不会直接调用——它们被封装在java.util.concurrent.atomic包里,比如AtomicInteger.incrementAndGet()内部就走CAS循环。
关键点在于:CAS操作是“乐观”的,它假设没有竞争,先读取当前值A,再尝试把值从A更新为B;如果期间其他线程改过这个变量(即内存中已不是A),整个操作就失败,通常会重试。
- 所有
Atomic*类(如AtomicReference、AtomicLong)都依赖CAS,不是synchronized或Lock -
Unsafe是受限API,JDK 9+默认禁止反射访问,所以别试图绕过Atomic*自己调compareAndSwapObject - CAS成功与否只看值是否匹配,不关心“谁改的”或“为什么改的”——这正是ABA问题的根源
ABA问题到底出在哪,为什么incrementAndGet不会暴露它
ABA问题发生在:某个变量值从A→B→A,而CAS操作只比对“当前是否等于A”,误判为“没人动过”,于是错误地执行了更新。典型场景是链表式结构(如无锁栈、无锁队列)中节点被回收又复用。
但像AtomicInteger.incrementAndGet()这种简单计数器基本不会遇到真实ABA问题,因为整型值极少出现“被改回原值还带语义正确性”的情况;而AtomicReference指向对象引用时,若对象被释放后又被新对象复用同一内存地址(尤其在非托管环境或某些JNI场景),才可能触发。
立即学习“Java免费学习笔记(深入)”;
Delphi 7应用编程150例 CHM全书内容下载,全书主要通过150个实例,全面、深入地介绍了用Delphi 7开发应用程序的常用方法和技巧,主要讲解了用Delphi 7进行界面效果处理、图像处理、图形与多媒体开发、系统功能控制、文件处理、网络与数据库开发,以及组件应用等内容。这些实例简单实用、典型性强、功能突出,很多实例使用的技术稍加扩展可以解决同类问题。使用本书最好的方法是通过学习掌握实例中的技术或技巧,然后使用这些技术尝试实现更复杂的功能并应用到更多方面。本书主要针对具有一定Delphi基础知识
- Java堆上对象地址由JVM管理,一般不会复用已回收对象的地址,所以纯Java代码中ABA概率极低
- 但并发数据结构(如
ConcurrentLinkedQueue)内部确实要处理ABA,它用的是带版本号的引用(AtomicStampedReference) - 不要以为“没看到报错”就代表没ABA——它可能导致逻辑错误而非崩溃,比如跳过本该处理的节点
AtomicStampedReference怎么破ABA,stamp真能防住所有情况
AtomicStampedReference把“值”和“版本戳(stamp)”打包成一对,CAS变成“比较值+戳都相等才更新”,每次修改值时主动递增stamp,从而区分A→B→A和真正的未修改。
AtomicStampedReferenceref = new AtomicStampedReference<>("A", 0); int[] stampHolder = {0}; String prev = ref.getReference(); int prevStamp = ref.getStamp(); boolean success = ref.compareAndSet(prev, "B", prevStamp, prevStamp + 1);
注意:stamp是int类型,有溢出风险(Integer.MAX_VALUE后变负),但实际中只要不每秒几百万次更新,基本不用怕。更关键的是——stamp必须由业务逻辑控制递增,不能全交给CAS自动管理。
- 如果你用
AtomicStampedReference但始终传同一个stamp值,那就跟普通AtomicReference没区别 - stamp不是时间戳,也不绑定系统时钟;它只是个手动维护的序列号,意义完全取决于你怎么用
- 某些场景下,stamp本身也可能被ABA(比如两个线程各自+1再-1),但概率远低于原始值ABA,且影响有限
还有没有更轻量或更彻底的替代方案
除了加stamp,还有两种常用思路:一种是彻底避免复用(如使用对象标识符代替引用),另一种是换数据结构(如用ThreadLocal隔离或改用ReentrantLock)。但这些都不是“通用解”,得看场景。
-
AtomicMarkableReference只带一个布尔标记位,适合只需要区分“是否被改过”的简单场景,比stamp省内存 - 无锁算法里常用“惰性删除”+“标记指针高位”(如用最低位做mark),但Java无法直接操作指针,得靠
Unsafe或VarHandle,JDK 9+推荐后者 - 别为了防ABA强行套
AtomicStampedReference——如果业务逻辑本身不依赖引用稳定性(比如只是缓存开关状态),那ABA根本无关紧要
真正容易被忽略的是:ABA从来不是独立存在的问题,它总和具体的数据结构设计耦合。没想清楚“为什么需要无锁”“哪些操作必须原子”之前,先别急着选方案。









