release方法通过检查head.next定位后继节点，因head为哑节点，真正等待者从head.next开始；若其为null或已取消，则从tail反向遍历找首个有效节点唤醒。
release 方法如何定位到头节点的后继节点
调用 release(int arg) 时，AQS 不会遍历整个队列找“第一个等待者”，而是直接检查当前 head 节点的 next 字段。这个设计依赖一个关键事实：只有成功获取资源并成为新 head 的节点，才会把原 head 的 next 指向自己，并清空原 head 的引用（即“出队”动作是前驱完成的）。所以当前 head.next 永远指向逻辑上最靠前、尚未被唤醒的等待线程节点。
常见错误现象是看到 head 节点的 thread 字段为 null，误以为它是个“空占位符”就该跳过——其实这正是 AQS 的设计：head 是哑节点（dummy node），只作队列锚点，真正等待的线程从 head.next 开始。
-
head初始化为空节点，不绑定任何线程 - 首个入队线程构造的 Node 成为
head.next，此时它才是实际等待者 - 释放操作中若
head.next == null或其waitStatus == CANCELLED，则跳过唤醒，避免无效 unpark
unparkSuccessor 为何只唤醒一个节点而非全部
在独占模式下，unparkSuccessor(Node node) 默认只唤醒 node.next，不是因为“懒”，而是语义约束：资源一次只能被一个线程占用。唤醒多个会导致竞争浪费，甚至破坏锁的互斥性。共享模式（如 Semaphore）才可能批量唤醒，但那由 doReleaseShared() 实现，路径完全不同。
容易踩的坑是误以为“唤醒 head.next 就等于唤醒了队列第一个有效节点”——其实还要过滤 CANCELLED 状态。AQS 会从 tail 往前扫描，找到离 head 最近的非取消节点再唤醒，确保不漏掉本该被调度的线程。
- 唤醒前先检查
node.next.waitStatus，若为CANCELLED，则循环查找下一个非取消节点 - 若找不到，就从
tail开始反向遍历，这是为了应对并发取消导致的next滞后更新问题 - 唤醒动作本身是通过
LockSupport.unpark(node.thread)，不抛异常、不阻塞、不可逆
为什么不是所有线程都能被 unpark 唤醒后立即执行
被 unpark 只是解除阻塞状态，线程回到 Runnable 状态，能否立刻抢到 CPU、是否能成功获取资源，取决于后续的自旋逻辑。关键在 acquireQueued(Node node, int arg) 中的 for 循环：它只在当前节点是 head.next 且 tryAcquire(arg) 成功时才退出，否则继续 park。
这意味着即使被唤醒，如果此时资源仍被占用（state > 0），或前驱节点还没完成出队（head 未更新），线程会再次调用 LockSupport.park() 阻塞——这不是 bug，而是防止忙等和虚假唤醒的必要机制。
- 唤醒 ≠ 获取成功，只是获得一次重试机会
- 重试时仍需检查前驱是否为 head，这是 CLH 队列的“守门”逻辑
- 若
tryAcquire失败，会再次设置node.waitStatus = SIGNAL，确保下次能被正确通知
state 更新与唤醒之间的时序安全怎么保障
AQS 所有对 state 的修改都通过 CAS（如 compareAndSetState(0, 1)），而唤醒操作发生在 tryRelease 返回 true 之后。也就是说，“资源已释放”的判断（state 归零）和“唤醒下一个”的动作之间没有竞态窗口——因为 tryRelease 本身必须原子地将 state 减至 0 才返回 true，而唤醒只在这个前提下触发。
性能影响在于：如果 tryRelease 是个重操作（比如需要校验持有线程、做嵌套计数），它会拖慢整个释放流程；但唤醒本身极轻量，不涉及锁或内存屏障（unpark 是 JVM 底层信号机制）。
-
state的 volatile 语义保证了唤醒线程能看到最新的 state 值 - 唤醒操作不依赖于 state 当前值，只依赖队列结构，因此不会因 state 波动而错判
- 非公平锁中，新线程可能在唤醒发生前就通过
tryAcquire抢走资源，这是设计使然，不是唤醒失效
