怎么通过分析 AQS 的信号量传播路径理解为何释放资源能精准唤醒队列首位线程

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