CAS不是锁，而是依赖CPU原子指令（如cmpxchg）实现的无锁并发控制，需配合volatile保证可见性，失败时通过重试而非阻塞来处理竞争，适用于低冲突场景。

为什么 CAS 不是“锁”却能保证线程安全

CAS 本质是一条 CPU 原子指令（比如 x86 上的 cmpxchg），不是 Java 层面的锁机制，也不进内核态。它靠硬件保证“比较+写入”这一步不可拆分——哪怕多个线程同时执行 compareAndSwapInt，也只会有一个成功，其余失败后立刻返回，不挂起、不阻塞、不切换上下文。

关键在于：它必须搭配 volatile 字段使用。否则线程可能一直读到自己工作内存里的旧值，导致预期值 E 永远不变，CAS 永远失败或永远“误成功”。volatile 强制每次读都从主内存拉最新值，写完立刻刷回主内存，这是 CAS 能工作的前提。

• 没加 volatile 的字段上用 AtomicInteger？行为未定义，大概率出错
• CAS 失败不等于出错，而是告诉你“值被别人改了”，得你自己决定重试还是放弃
• 高竞争下自旋开销明显，CPU 白跑循环；线程数远超 CPU 核心数时，性能反而不如 synchronized

AtomicInteger.getAndIncrement() 底层到底在干什么

调用 getAndIncrement() 时，JVM 实际执行的是 Unsafe.getAndAddInt()：先用 getIntVolatile() 读当前值 V，再用 compareAndSwapInt(obj, offset, V, V + 1) 尝试更新。失败就重试，直到成功为止。

这个过程没有锁对象、没有 monitor entry、不触发线程调度——但它是“乐观”的：假设冲突少，靠重试兜底。所以适合计数器、状态标志位这类低竞争、单变量、操作快的场景。

• 不要在循环里反复调用 getAndIncrement() 做大量累加——每次都是独立 CAS，失败重试成本叠加
• 想批量加 100？别写 100 次 incrementAndGet()，用 addAndGet(100) 一次到位
• lazySet() 和 set() 都写值，但前者不保证后续读的可见顺序，仅适用于“只写不读”的发布场景（如链表尾指针更新）

ABA 问题不是理论陷阱，是真实会崩掉逻辑的 Bug

线程 A 读到值 A，准备 CAS 成 B；此时线程 B 把 A → B → A 改了两轮；A 再执行 CAS 时发现还是 A，就直接写入——但语义已错：中间状态丢失了。

典型例子是并发栈的 pop 操作：头节点被弹出又压回同个对象，CAS 认为“没变”，实际栈结构已被破坏。

• 用 AtomicStampedReference 加版本号，每次修改 stamp +1，CAS 变成“值+版本”双校验
• 用 AtomicMarkableReference 加一个布尔标记位，适合只需要区分“是否被改过”的轻量场景
• 别自己用 long 拼戳记——高位存版本、低位存引用，容易因 GC 移动对象地址而失效（Java 9+ 后 Unsafe.objectFieldOffset 对压缩指针有兼容性风险）

Unsafe 类为什么“危险”，又为什么绕不开

sun.misc.Unsafe 是 JUC 原子类的底层引擎：所有 compareAndSwapXXX、putObjectVolatile、objectFieldOffset 都依赖它。但它绕过 JVM 安全检查，可直接读写内存地址、强制实例化抽象类、甚至篡改 final 字段。

Java 9 开始模块化后，默认禁止应用代码反射访问 Unsafe；Java 17 更进一步限制其部分方法。但 JUC 内部仍通过特权块调用——你写业务代码不该碰它，但得知道 Atomic 类背后是它在扛。

• 别在应用里 try-catch PrivilegedActionException 去硬取 Unsafe 实例，JDK 版本一升级就挂
• VarHandle（Java 9+）是官方推荐替代方案，API 更安全、语义更清晰，但目前 Atomic 类还没全面迁过去
• 看到堆栈里出现 Unsafe.compareAndSwapInt 不用慌——那是正常路径；但如果自己代码里出现了，基本可以删了

真正难的从来不是“怎么调用 incrementAndGet”，而是判断该不该用它、值被谁改过、失败后要不要等、以及当多个字段要一起变时——CAS 已经帮不上忙了。