CLH队列实现公平锁，AQS原理全解析

本文深入剖析了AQS中公平锁的底层实现机制，揭示CLH队列并非物理链表而是基于volatile状态协作的逻辑自旋等待结构——每个线程通过本地Node的pred指针监听前驱节点的status字段（如SIGNAL/-1）来决定是否获取锁，真正维系队列秩序的是线程间对前驱状态的原子读写与内存可见性保障；文章澄清了AQS对原始CLH的關鍵改造动机（解决NUMA伪共享、支持取消与中断）、详解了shouldParkAfterFailedAcquire的渐进式清理逻辑、对比了公平锁与非公平锁在tryAcquire时机和队列准入判断上的本质差异（尤其是hasQueuedPredecessors的无遍历高效实现），并给出实用的调试建议：摒弃静态字段观察，转而依赖诊断方法与waitStatus状态机理解真实排队行为——理解CLH，核心不在指针如何连，而在状态何时变、为何可见、怎样安全流转。

CLH队列不是链表，是逻辑上的自旋等待队列

很多人一看到“CLH”就默认是双向链表结构，直接去翻 AbstractQueuedSynchronizer 里的 Node 字段，结果发现 prev 和 next 并不用于构建真实链表——它们只在取消或超时时做清理用。CLH 的核心是每个线程持有一个本地的 Node，靠 pred 指针指向前驱节点的 status 字段来判断是否该轮到自己获取锁。

• 真正构成“队列”的是线程间对前驱 status 的 volatile 读写，不是指针遍历
• Node 初始化时 status = 0，入队后被设为 Node.SIGNAL（-1），表示“唤醒后继”
• 前驱节点释放锁时，会把自身 status 设为 0，并调用 LockSupport.unpark() 唤醒后继——但这个唤醒动作不一定立即生效，后继仍需自旋检查前驱状态

为什么 AQS 不直接用 CLH 原始版本而要改造？

原始 CLH 锁在 NUMA 架构下有缓存行伪共享问题，且无法支持取消操作。AQS 改造成“变种 CLH”：把前驱节点的 status 当作信号位，同时允许节点在中断或超时时主动出队。

• 原始 CLH 要求所有线程严格按入队顺序退出，AQS 必须支持 Thread.interrupt() 或 tryAcquireNanos() 中断，所以引入 CANCELLED（1）状态并做惰性清理
• shouldParkAfterFailedAcquire() 是关键函数：它不断跳过已取消的前驱，直到找到一个有效 SIGNAL 节点才返回 true，否则返回 false 触发重试
• 如果前驱是 CANCELLED，当前节点会尝试用 CAS 把前驱的 next 指向自己，实现“剪枝”，但这步不保证成功，所以清理是渐进式的

公平锁里 acquire() 和 tryAcquire() 的调用时机差异

公平锁的 lock() 方法最终走的是 acquire(1)，但它在真正排队前会先调用一次 tryAcquire(1) —— 这次调用会检查队列是否为空、且当前线程是不是队首，而不是简单看 state 是否为 0。

• 非公平锁的 tryAcquire() 只检查 state == 0 就尝试 CAS 设置；公平锁则额外加了 !hasQueuedPredecessors() 判断
• hasQueuedPredecessors() 的实现很精巧：它不遍历队列，而是检查 head.next != currentNode 且 head.next != null，本质是判断当前线程是否是队列中第一个等待者
• 这个判断必须放在 CAS 之前，否则可能刚检查完队列为空，另一线程就插入头部，导致插队——所以公平锁的“公平性”其实是在入队那一刻确定的，不是在唤醒时

调试时怎么看 CLH 队列实际状态？

别依赖 IDE 的变量视图看 AQS 内部字段，head 和 tail 是 volatile 的，且节点随时可能被取消或唤醒，静态快照意义不大。真正有用的是 getQueueLength() 和 hasQueuedThreads() 这类诊断方法，或者打日志时记录 Thread.currentThread().getName() + node.waitStatus。

• node.waitStatus 的常见值：0（初始）、-1（SIGNAL）、1（CANCELLED）、-2（CONDITION）、-3（PROPAGATE）
• 注意 waitStatus == 0 不代表节点无效，可能是刚入队还没被前驱标记 SIGNAL，也可能是前驱刚释放锁正在唤醒它
• 用 jstack 查线程堆栈时，阻塞在 Unsafe.park() 的线程大概率在 CLH 队列中，但不能反推：有些线程 park 是因为条件队列（ConditionObject），不是 AQS 同步队列

CLH 的难点不在结构本身，而在状态流转的时机和内存可见性保障——比如前驱改 status 和后继读 status 之间，靠的是 volatile 语义和 JVM 的 happens-before 规则，不是锁或 synchronized。这点一旦想错，就容易在复现竞争 bug 时绕弯路。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。