releaseshared 唤醒 head.next 或其后首个非 cancelled 节点，因 aqs 同步队列是 fifo 双向链表，head 为哨兵节点；唤醒由 doreleaseshared 中 cas 循环驱动，确保不丢失、不重复；传播是否继续取决于 tryreleaseshared 返回 false（有资源剩余）还是 true（释放完毕）。
为什么 releaseShared 唤醒的是头节点，而不是任意节点
因为 AQS 的同步队列是严格 FIFO 的双向链表，head 指针只指向「已获取资源并正在运行」的节点（即已出队），而真正等待唤醒的首个线程，实际在 head.next 位置。释放操作不靠遍历，而是直接检查 head.next 是否存在且状态合法（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></pid>查看线程堆栈，确认等待线程是否处于Unsafe.park状态，且阻塞在acquireQueued或doAcquireShared - 在自定义同步器中重写
toString()，打印当前state和head/tail地址，配合Unsafe.addressSize()辅助定位
最容易被忽略的点：传播路径是否生效，不只看唤醒动作，更要看被唤醒线程能否真正拿到资源。如果 tryAcquireShared 因逻辑错误始终返回负数，即使 unpark 成功，线程也会立刻重新挂起 —— 此时问题不在 AQS 底层，而在子类对 state 的语义定义。
