CAS在低冲突时一次成功、零等待，性能优于悲观锁；高冲突时频繁自旋导致CPU空转、业务重复执行，此时悲观锁更稳。
CAS 自旋锁在低冲突和高冲突场景下的性能差异，根源在于“失败重试”带来的资源消耗是否可控——低冲突时自旋几乎不发生，高冲突时自旋变成无效空转。
低冲突场景：一次成功，零等待开销
当多个线程极少同时修改同一变量（比如全局计数器、开关标志、秒杀预减库存），CAS 操作绝大多数能一次性命中。此时：
- 无需自旋，不消耗额外 CPU 时间
- 全程在用户态完成，无线程挂起/唤醒、无内核态切换
- AtomicInteger.incrementAndGet() 这类操作吞吐量高、延迟稳定
- 相比 synchronized，避免了 Monitor 入口竞争、锁膨胀等 JVM 开销
高冲突场景：频繁失败，CPU 白忙
若大量线程反复争抢同一热点变量（如账户余额、订单状态字段），CAS 会持续失败并触发自旋重试：
- 线程在用户态死循环检查，单核可能跑满却无实际进展
- 每次失败后需重新读取、比对、计算，业务逻辑重复执行（例如反复查库存、重算金额）
- 自旋本身不释放 CPU，挤占其他有用任务的执行时间
- 此时 synchronized 虽然阻塞，但让出 CPU 给 OS 调度，系统整体更平稳
自旋不是万能优化，而是有代价的“乐观假设”
自旋锁本质是赌“锁很快会被释放”，它把线程调度成本换成了 CPU 时间成本：
立即学习“Java免费学习笔记（深入）”；
- 适合锁持有时间极短（纳秒~微秒级）、且冲突概率低的场景
- JVM 的轻量级锁默认自旋 10 次，超时即升级为重量级锁，就是为防止空转失控
- 单纯堆自旋次数（如用 while(true) 不设上限）反而恶化性能，不是越“努力”越快
选择依据不在“锁还是不锁”，而在“冲突是否可预期”
真正决定用 CAS 还是 synchronized / ReentrantLock 的，不是并发量大小，而是写操作的竞争密度：
- 读多写少 + 写操作分散 → CAS 原子类或自旋锁更优
- 写密集 + 热点变量集中 → 悲观锁更稳，哪怕排队也比空转强
- 混合场景可分层处理：用 StampedLock 的乐观读 + 必要时降级为悲观写
