CAS能力由Unsafe类提供，但开发应使用java.util.concurrent.atomic包中的AtomicInteger等封装类；它们通过compareAndSet接口屏蔽底层细节，并已处理自旋、内存屏障与重试逻辑。
Java里CAS到底在哪个类里用
CAS不是Java语言直接提供的语法，而是Unsafe类暴露的底层能力，实际开发中你几乎不会直接调它。真正该关注的是java.util.concurrent.atomic包下那一套封装好的类，比如AtomicInteger、AtomicReference——它们内部调用Unsafe.compareAndSwapInt等方法，但对外只暴露compareAndSet这种语义清晰的接口。
常见错误现象：有人想绕过AtomicInteger自己用Unsafe写CAS逻辑，结果发现Unsafe.getUnsafe()抛SecurityException；这是因为JDK限制了非系统类加载器访问Unsafe，强行反射绕过会破坏JVM稳定性。
- 用
AtomicInteger.compareAndSet(expected, update)替代手写CAS循环，它已处理自旋、内存屏障和失败重试 - 注意
expected是“当前期望值”，不是“初始值”；如果多线程并发修改，expected可能早已失效 -
AtomicLong在x64上通常用单条cmpxchg指令实现，但32位JVM对long的CAS需依赖锁降级，性能有落差
CAS失败时为什么不能直接return false就完事
典型场景：实现无锁栈或无锁队列时，仅靠一次compareAndSet返回false就放弃操作，会导致数据丢失或无限重试。CAS本质是乐观策略，失败只说明“此刻值被别人改了”，不代表操作本身无效。
关键点在于：是否需要重试，取决于业务逻辑对“状态一致性”的要求。比如计数器累加必须成功，就得循环直到compareAndSet返回true；而某些幂等更新（如设置标志位）允许跳过。
立即学习“Java免费学习笔记（深入）”；
- 标准重试写法是
while (!atomicRef.compareAndSet(oldVal, newVal)) { oldVal = atomicRef.get(); }，别漏掉重新读取最新值 - 无界自旋可能饿死线程，高竞争场景建议结合
Thread.yield()或短时LockSupport.parkNanos(1) -
AtomicStampedReference通过引入版本号解决ABA问题，但要注意“版本号”本身也得用CAS更新，否则又回到原点
volatile和CAS能互相替代吗
不能。两者解决的问题维度不同：volatile保证可见性和禁止重排序，但不保证复合操作原子性；CAS则是在可见性基础上，提供“读-改-写”这一整套动作的原子性。
典型误区：有人以为给一个volatile int counter，再用counter++就能线程安全——错。因为counter++包含三步：读取、+1、写回，中间可能被其他线程插入修改。
-
volatile字段可被CAS类安全读写，但普通volatile变量自身不支持compareAndSet - CAS操作隐式包含
volatile读写语义（JMM规定），所以不需要额外加volatile修饰AtomicInteger字段 - 过度依赖
volatile模拟CAS（比如先读再if判断再赋值）会产生竞态条件，这不是原子操作
为什么ConcurrentHashMap要用CAS而不是synchronized
核心原因是粒度。早期ConcurrentHashMap（JDK 7）用分段锁（Segment），JDK 8彻底转向CAS + synchronized细粒度锁混合：数组初始化、扩容触发、链表转红黑树这些关键节点用CAS保障结构安全，而单个桶（bin）的插入/删除在冲突时才用synchronized锁住头节点。
这样做既避免全局锁瓶颈，又规避纯CAS在高冲突下的CPU空转浪费。如果你看到Node类里大量casNext、casValue调用，那正是CAS在维护链表/树结构的线程安全。
- 数组扩容时，多个线程可能同时检测到容量不足，靠
transferIndex字段的CAS递减来分配迁移任务，避免重复工作 - 链表头插法用
casNext确保新节点正确挂载，失败就重试，而不是直接锁整个桶 - 注意
sizeCtl这个控制字段：负数表示正在扩容，它的变更全部走CAS，是整个扩容流程的协调中枢
