cas是cpu提供的原子指令，java通过unsafe.compareandswapint等方法暴露，atomicinteger等类底层依赖它实现无锁更新；其核心是“比较并交换”，仅当内存值等于预期旧值时才更新为新值。
什么是CAS？它在Java里怎么被调用
CAS（Compare-And-Swap）不是Java语言关键字，而是CPU提供的一条原子指令，在Java中通过Unsafe.compareAndSwapInt等底层方法暴露出来。JDK的java.util.concurrent.atomic包里所有AtomicInteger、AtomicReference等类，内部都依赖它实现无锁更新。
典型使用场景是避免加锁做计数器或状态切换：比如多个线程同时对一个计数器+1，用incrementAndGet()比synchronized更轻量。
关键点在于：CAS操作有三个参数——内存位置V、旧值A、新值B；仅当V当前值等于A时，才把V设为B，并返回true；否则返回false，不修改V。
常见错误现象：写自定义无锁结构时直接调用Unsafe，却忽略不同JVM版本中Unsafe字段名或获取方式差异（如JDK 9+模块限制），导致NoAccessError或IllegalAccessException。
立即学习“Java免费学习笔记（深入）”；
ABA问题到底是什么，为什么它危险
ABA问题不是“值变回去了所以没问题”，而是指：某个变量V初始为A，被线程1读取后，被线程2修改为B又改回A；此时线程1执行CAS判断“还是A”，就误认为没被干扰，继续更新——但中间状态已丢失，逻辑可能出错。
典型场景：AtomicReference用于实现无锁栈或队列时，节点被弹出（A→B）、回收、再分配（B→A），导致CAS成功却指向了错误内存地址。
这不是理论风险：在高并发对象池、内存复用、链表结构中真实发生过，且极难复现和调试。
注意：AtomicInteger这类纯数值类型一般不构成实质危害（比如计数器从100→101→100，再+1变成101，业务上未必算错），但AtomicReference指向对象引用时，ABA意味着对象身份已变更，必须警惕。
怎么解决ABA？AtomicStampedReference不是万能药
AtomicStampedReference通过给引用搭配一个整型“戳记”（stamp），把CAS从二维（引用）扩展成三维（引用+stamp），每次更新都要求引用和戳记同时匹配。这是最常用的ABA缓解手段。
但要注意几个现实约束：
- 戳记是int类型，存在溢出回绕风险（虽然概率极低，但金融/长期运行系统需评估）
- 每次
compareAndSet必须传入当前戳记值，不能只靠getStamp()——因为get和CAS之间可能已被其他线程更新，必须用get(int[] stampHolder)原子读取二者 - 它只解决“是否被改过”的问题，不解决“改成了什么”——如果你需要完整变更历史，得自己记录日志或用
AtomicMarkableReference（布尔标记）或自定义结构
AtomicStampedReference<Node> ref = new AtomicStampedReference<>(head, 0); int[] stamp = new int[1]; Node current = ref.get(stamp); int oldStamp = stamp[0]; // ……处理逻辑 boolean success = ref.compareAndSet(current, newNode, oldStamp, oldStamp + 1);
还有没有更彻底的替代方案
真正规避ABA，核心思路是让“相同值≠相同身份”。除戳记外，还有几种工程化选择：
- 用
AtomicMarkableReference：适合只需区分“是否被修改过”的场景（如标记节点是否已删除），空间开销更小 - 不复用对象：在对象池中禁用立即重用，加入延迟释放或GC友好的弱引用缓存，从源头切断ABA路径
- 换数据结构：某些场景下，用
ConcurrentLinkedQueue代替手写无锁队列，它内部用“tail节点两次检查”策略绕过ABA依赖 - JDK 17+的
VarHandle：虽不直接解决ABA，但提供了更安全、标准化的原子访问接口，配合WeakPair等模式可构建更可控的版本控制
别迷信“加个stamp就万事大吉”。实际排查时，先确认你的场景是否真受ABA影响——比如只是计数器，那大概率不需要折腾戳记；如果是自定义无锁容器，就得严格验证ABA路径，并在测试中注入模拟ABA的干扰线程。
