CAS 为什么效率高？

CAS 的高效核心在于“无锁”和“硬件原子指令”两个层面避免了传统锁的诸多开销。无需操作系统内核态切换最核心的优势传统互斥锁线程获取锁失败会进入阻塞状态如调用pthread_mutex_lock这需要操作系统介入完成“用户态 → 内核态 → 用户态”的切换。一次上下文切换的代价可能高达几万到几十万个 CPU 时钟周期。CAS全部操作都在用户态完成。它只是一条 CPU 原子指令如 x86 的cmpxchg。执行时要么成功要么失败立即返回不会主动让线程挂起。这避免了系统调用和上下文切换的昂贵开销在临界区极短的场景下性能提升是指数级的。乐观的非阻塞策略延迟极低CAS 的默认态度是“乐观”的假设没有冲突直接尝试修改。如果没冲突指令就瞬间完成延迟极低。相比之下锁是“悲观”的会先假设有冲突必须独占。细粒度的原子操作锁保护的是一段代码块而 CAS 直接保护对一个单个变量的更新。这种极致的细粒度为 AQS 中state、waitStatus等字段的无锁化操作提供了基础。在 AQS 中的体现大量并发线程争用锁时首先通过 CAS 对state进行“光速”抢占。抢不到才去构建队列这是高吞吐量的关键。CAS 有什么缺点吗它的优点也是它缺点的根源主要有三个问题1. 经典的 ABA 问题这是由 CAS “只看表面值”的机制决定的。问题线程 T1 读取值 A → 线程 T2 将 A 改为 B 又改回 A → 线程 T1 执行 CAS发现值还是 A误以为从未被修改过从而成功更新。后果在某些场景下这个“没变”隐藏了逻辑错误。比如用 CAS 管理一个栈顶指针如果原节点 A 被回收并恰好又作为新节点放回CAS 会成功但链表结构可能已错乱。解决引入版本号如 Java 的AtomicStampedReference。AQS 的state和waitStatus等字段其业务语义不关心中间历史只关心当前状态符不符合预期所以 ABA 问题在 AQS 内部通常无害。2. 循环自旋带来的 CPU 空转开销这是 CAS 在竞争激烈时暴露的最大缺陷。问题CAS 失败后通常会使用while循环不断重试即自旋。如果竞争激烈大量线程都在疯狂自旋会导致 CPU 资源被严重浪费甚至拖慢整个系统。AQS 的智慧AQS 正是为了解决这个缺点而设计的。它让线程的等待分为两个阶段短暂自旋尝试几次 CAS适用于锁很快就释放的场景。挂起等待如果多次自旋失败就用LockSupport.park()让线程进入休眠彻底释放 CPU。当锁被释放时再由前驱节点精确唤醒。这本质上是用“锁队列”的机制来弥补 CAS 在长期等待时的低效。这正是 AQS 对 CAS 缺点的完美修补。3. 只能保证单个变量的原子性局限CAS 指令本身只能对一个内存地址进行原子操作。后果如果想让多个共享变量同时原子地更新比如转帐场景A 账号减钱B 账号加钱用一次 CAS 就无法实现。此时必须借用锁或者用更复杂的原子类如AtomicReference配合不可变对象的设计。总结一下CAS 和 AQS 的关系是CAS 是无锁原子操作的“快进键”负责在低竞争时极速通行而 AQS 则是当“快进键”失效时自动切换到的“有序排队系统”负责用挂起/唤醒的方式优雅地管理高并发冲突并解决 CAS 自身的自旋消耗和功能局限。