如何通过分析 AQS 信号量传播路径，解析释放资源精准唤醒队列首位线程的原理？

本文共计1339个文字，预计阅读时间需要6分钟。

AQS（AbstractQueuedSynchronizer）的同步队列是严格的FIFO双向链表，节点指向的是已获取资源且正在执行的节点（即已出队节点），而真正等待唤醒的是队列头部的第一个线程节点。释放操作不依赖于遍历，而是直接检查队列头节点的状态，判断其是否满足释放条件（如`waitStatus !=CANCELLED`），然后调用`LockSupport.unpark(node.thread)`唤醒它——这就是精准的来源：

常见错误现象：unparkSuccessor 中跳过 CANCELLED 节点时，若连续多个节点被取消，可能最终唤醒的是 head 后第 N 个节点。这不是 bug，而是设计使然：AQS 不保证唤醒「第一个未取消节点」以外的任何顺序，但保证不会漏掉它。

• head 本身是哨兵节点，不关联真实线程；真正待唤醒的线程总在 head.next 或其后第一个非 CANCELLED 节点
• 共享模式下，releaseShared 成功后会循环调用 doReleaseShared，确保传播不中断
• 如果 head.next == null 或为 CANCELLED，AQS 会尝试从 tail 往前扫描，但这是兜底逻辑，非常态路径

tryReleaseShared 返回值如何影响唤醒传播

共享模式的唤醒是否继续向下传递，完全取决于 tryReleaseShared 的返回值：仅当它返回 true 时，AQS 才认为资源已彻底释放完毕，停止传播；若返回 false，则立即触发下一轮 doReleaseShared 尝试唤醒后继。这和独占模式的 tryRelease（只返回 true/false 表示是否成功释放）有本质区别。

典型场景：一个 Semaphore(2) 被三个线程 acquire()，state 变为 -1。此时调用一次 release()（即 releaseShared(1)），tryReleaseShared 内部执行 state = 0 并返回 false → 触发传播 → 唤醒第一个等待者；该线程获取后 state 变为 -1，再次释放时 state = 1，仍返回 false → 继续唤醒第二个；直到某次释放后 state > 0 且无更多等待者，才可能返回 true。

• 返回 false ≠ 失败，而是“还有资源剩，接着唤”
• 子类实现中必须用 compareAndSetState 保证原子性，否则可能漏传或重复传播
• 若误将 tryReleaseShared 实现为总是返回 true，传播就断了，后续等待线程永远休眠

为何 unparkSuccessor 不在 release 中直接调用

release（独占）和 releaseShared（共享）都只负责更新 state 和判断是否需要传播，真正的唤醒动作由 unparkSuccessor 承担，且它被封装在 doReleaseShared 的 CAS 循环里。这么做不是为了复杂化，而是解决两个并发关键点：

• 避免唤醒丢失：线程 A 正在 acquireQueued 自旋检查前驱是否为 head，同时线程 B 执行 release 并直接 unpark —— 若此时 A 还未入队或刚入队但 next 未连好，unpark 就无效。CAS 循环能重试直到结构稳定
• 防止重复唤醒：多个线程并发 release 时，doReleaseShared 用 compareAndSetState 控制传播节奏，确保同一轮传播只由一个线程主导
• unparkSuccessor 本身不持有锁，但它依赖 head 和 tail 的 volatile 语义来读取最新队列视图

调试时怎么验证信号量传播路径是否正常

最直接的方式是打日志或断点观察 AbstractQueuedSynchronizer.doReleaseShared 的执行次数、head 和 head.next 的变化，以及每次 unpark 的目标线程。但要注意：不要在生产环境用 System.out 打点，它会严重干扰线程调度和 CAS 性能。

更可靠的做法是结合 JUC 源码 + JVM 参数：

• 启动参数加 -Djava.util.concurrent.locks.AbstractQueuedSynchronizer.dump=true（需自行 patch 或用调试版 JDK）可输出队列快照
• 用 jstack <pid> 查看线程堆栈，确认等待线程是否处于 Unsafe.park 状态，且阻塞在 acquireQueued 或 doAcquireShared
• 在自定义同步器中重写 toString()，打印当前 state 和 head/tail 地址，配合 Unsafe.addressSize() 辅助定位

最容易被忽略的点：传播路径是否生效，不只看唤醒动作，更要看被唤醒线程能否真正拿到资源。如果 tryAcquireShared 因逻辑错误始终返回负数，即使 unpark 成功，线程也会立刻重新挂起 —— 此时问题不在 AQS 底层，而在子类对 state 的语义定义。