CAS是JVM通过Unsafe调用CPU硬件指令（如x86的CMPXCHG）实现的原子操作，依赖volatile保证可见性、硬件指令保证原子性；AtomicInteger.incrementAndGet()采用乐观自旋重试，高并发下可能大量失败；ABA问题需AtomicStampedReference解决；CAS仅保障单变量原子性，不可替代多字段/复合操作的锁机制。
Java里CAS靠Unsafe类和CPU指令硬实现
CAS不是Java语言层面的语法糖，而是由JVM借助Unsafe类调用操作系统底层指令完成的原子操作。你在AtomicInteger里看到的compareAndSet()，最终都会落到Unsafe.compareAndSwapInt()这个native方法上；而它背后，在x86架构下实际执行的是CMPXCHG汇编指令——这条指令由CPU硬件保证“读-比-写”三步不可分割，不会被线程调度打断。
关键点在于：volatile字段提供可见性（让每次读都是最新值），Unsafe提供原子性（靠硬件指令锁总线或缓存行），两者缺一不可。如果你自己用普通int变量+手动if判断再赋值，那就是典型的非原子check-and-set，完全不安全。
为什么AtomicInteger.incrementAndGet()要自旋重试
因为CAS失败后不阻塞，只返回false，上层逻辑必须主动重试。看incrementAndGet()源码里的do-while循环：
public final int incrementAndGet() {
int prev, next;
do {
prev = get(); // 读当前值
next = prev + 1; // 算新值
} while (!compareAndSet(prev, next)); // 失败就重来
return next;
}
这种“乐观重试”在低竞争时极快，但高并发下可能反复失败几十次——比如100个线程同时对同一个AtomicInteger做++，大概率前99次都白读、白算、白CAS，纯耗CPU。这不是bug，是设计取舍：用CPU空转换掉锁带来的上下文切换开销。
立即学习“Java免费学习笔记（深入）”；
- 别在循环体里加日志或sleep，会放大问题
- 如果业务逻辑本身较重（比如要查DB再更新），CAS就不适合，该用
ReentrantLock或数据库行锁
ABA问题不是理论陷阱，真实转账场景会出错
假设账户余额从100 → 被A线程扣50（预期100→50）→ 又被B线程充30（100→130）→ 再被C线程扣80（130→50）。此时A线程的CAS仍会成功：它只看到“当前值还是100”，却不知道中间经历过130。结果是两次扣款叠加，余额错乱。
Java提供了AtomicStampedReference来解决，它把版本号（stamp）和值打包成一对，CAS时同时校验二者：
AtomicStampedReferenceref = new AtomicStampedReference<>(100, 0); int[] stamp = {0}; Integer cur = ref.get(stamp); // 同时取出值和版本号 ref.compareAndSet(cur, 50, stamp[0], stamp[0] + 1); // 值和版本号必须都匹配
注意：版本号不能简单用int自增，得确保每次修改都唯一；否则多线程下stamp也可能ABA。生产环境建议用Long或AtomicInteger管理stamp。
别把CAS当万能锁，它只保单变量原子性
CAS只能保证一个内存地址上的读-改-写原子，无法跨字段、跨对象协调。比如你要实现“扣款+记日志”原子化，AtomicInteger和AtomicReference各自独立，CAS成功一个不代表另一个也成功。
常见误用：
- 用多个
Atomic*模拟复合状态（如status+timestamp），结果状态不一致 - 以为
AtomicReference能替代synchronized锁整个方法块 - 在CAS循环里调用非幂等方法（如发MQ消息），重试导致重复投递
真正需要多字段/多步骤原子性时，要么用锁，要么用STM（软件事务内存）类库，或者直接交给数据库事务处理——CAS的边界，就是单个volatile字段的原子更新。
记住：CAS不是“更高级的锁”，它是另一种并发模型。用对场景才叫无锁，用错地方就是埋雷。
