AQS信号量释放为何唤醒首线程

AQS信号量的唤醒机制之所以能精准定位并唤醒队列中首个有效等待线程，并非依赖低效的遍历查找，而是巧妙依托“head为哑节点、head.next恒指逻辑上第一个未被唤醒的有效节点”这一核心结构约束，辅以waitStatus状态的精细协同——CANCELLED状态用于跳过已取消节点确保安全性，PROPAGATE状态则在共享模式下保障释放动作的级联传播，避免资源充足却线程阻塞的死锁风险；这种设计将正确性锚定在不变量与状态语义的深度耦合之上，一旦破坏（如篡改next引用或忽略状态校验），整个唤醒逻辑便立即失效。

释放资源时能精准唤醒队列首位线程，根本原因不是“遍历找第一个”，而是靠 head.next 的语义保证 + 状态过滤机制。

为什么 head.next 就是逻辑上“第一个该被唤醒的节点”

AQS 的 head 永远是哑节点（dummy node），不绑定任何线程，只作队列锚点。真正等待的线程从 head.next 开始。

• 首个入队线程构造的 Node 会成为 head.next，此时它才是实际等待者
• 后续成功获取资源的线程在 setHead 时，会把前驱节点（原 head）的 next 指向自己，并清空原 head 的引用 —— 这个“出队”动作由前驱完成，所以当前 head.next 始终指向尚未被唤醒、且在队列中位置最靠前的有效节点
• 常见错误是看到 head.thread == null 就以为要跳过，其实这正是设计：不能拿 head 的 thread 字段判断是否有效

unparkSuccessor 为何不直接 unpark head.next

unparkSuccessor 不是无条件唤醒 head.next，而是先做状态校验和兜底查找。

• 先检查 head.next != null 且 head.next.waitStatus != CANCELLED；若不满足，就跳过
• 若 head.next 已取消或为 null，则从 tail 开始反向遍历，找离 head 最近的非取消节点 —— 这是为了应对并发取消导致的 next 字段滞后更新
• 唤醒动作本身是 LockSupport.unpark(node.thread)，不抛异常、不阻塞、不可逆，但只是解除阻塞状态，不代表线程立刻执行

共享模式下为何需要 PROPAGATE 状态

在 Semaphore 或 CountDownLatch 这类共享场景中，“唤醒一个”不够，必须支持传播，否则资源明明够用，后续线程却卡死。

• Node.SIGNAL 表示“后继需被唤醒”，是通用信号；Node.PROPAGATE 是共享专属状态，含义是“即使当前没明确信号，也要继续传播释放动作”
• 典型竞态：T1 执行 releaseShared() 时，新 head 的 waitStatus 还是 0（刚设为 head，还没来得及设 SIGNAL），T1 就 CAS 成功设为 PROPAGATE，防止信号丢失
• 之后若有线程调用 setHeadAndPropagate，会检查新 head 的状态，若为 PROPAGATE 或 SIGNAL，就会继续尝试唤醒后继，形成级联

真正容易被忽略的是：唤醒的“精准性”不来自暴力扫描，而来自队列结构约束（head.next 的不变量）+ 状态字段的协同（CANCELLED 过滤、PROPAGATE 补偿）。一旦破坏这个结构（比如手动修改 next 或忽略 waitStatus），唤醒逻辑就不可靠了。

好了，本文到此结束，带大家了解了《AQS信号量释放为何唤醒首线程》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！