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。
立即学习“Java免费学习笔记（深入）”；
-
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 时绕弯路。
