AQS的SIGNAL位如何理解，后继线程为何需前驱线程显式标记改写为CAS，入队前长尾词疑问？

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

由于 `SIGNAL` 的语义是当我释放锁时，必须 unpark 我的后继，这个责任只能由前驱节点承担——即后继线程还未完成、甚至还未开始构造 `Node` 时。基本无法安全地给自己或他人设置状态。

常见错误现象：有人试图在 enq() 中让新节点一入队就 compareAndSetWaitStatus(this, 0, SIGNAL)，结果要么 CAS 失败（前驱还没来得及更新），要么逻辑错乱（此时前驱可能还是 head，而 head 的 waitStatus 本不该是 SIGNAL）。

• SIGNAL 是一种“委托唤醒”契约：只有当前节点确认自己会释放资源（比如调用 release()），才配把 SIGNAL 设给前驱
• 前驱节点设 SIGNAL 的时机，是在它准备 park() 自己之前，用 compareAndSetWaitStatus(p, 0, SIGNAL) 尝试标记自己为“可唤醒后继”
• 如果 CAS 失败（比如前驱已被其他线程设为 CANCELLED），说明队列状态已变，当前线程应重试或放弃入队

入队过程中谁在什么时候修改 waitStatus 为 SIGNAL

不是后继线程设的，也不是 AQS 构造器自动设的，而是前驱节点在挂起自己前，通过 shouldParkAfterFailedAcquire() 循环中的一次 CAS 设置。

典型流程（以 acquireQueued() 为例）：

• 线程 A 尝试 acquire() 失败 → 调用 addWaiter(Node.EXCLUSIVE) 入队 → 成为 tail
• 进入 acquireQueued(node, arg) 循环，先检查前驱是否是 head
• 如果不是，调用 shouldParkAfterFailedAcquire(p, node)，其中 p 是前驱节点
• 该方法会判断：p.waitStatus == SIGNAL → 直接返回 true；否则尝试 compareAndSetWaitStatus(p, 0, SIGNAL)
• 只有这次 CAS 成功，才表示“前驱已承诺会在释放时唤醒我”

注意：compareAndSetWaitStatus(p, 0, SIGNAL) 的第一个参数是前驱节点 p，不是当前节点 node —— 这个细节决定了谁对唤醒负责。

SIGNAL 为 0 或 CANCELLED 时后继线程的行为差异

后继线程是否能安全挂起，完全取决于前驱的 waitStatus 值。这不是约定，而是 AQS 的硬性守门逻辑。

• waitStatus == SIGNAL：前驱已明确承诺唤醒，当前线程可放心 LockSupport.park()
• waitStatus == 0：前驱尚未设 SIGNAL，当前线程不能 park，必须继续循环等待或帮前驱设状态
• waitStatus == CANCELLED（值为 1）：前驱已失效，需跳过它，往前找第一个非 CANCELLED 前驱；找不到则重试入队
• waitStatus == CONDITION 或 PROPAGATE：说明前驱不在同步队列主路径上，当前线程需重新评估排队位置

性能影响：这个检查看似多一次 volatile 读 + 可能的 CAS，但避免了无谓的 park/unpark 开销。实测中，95% 以上场景在第二次循环就能看到 SIGNAL，无需自旋太久。

容易被忽略的关键点：SIGNAL 不是“我等着被唤醒”，而是“我负责唤醒下一个”

这是最常被误解的地方。SIGNAL 存在于前驱节点上，描述的是前驱节点的义务，不是后继节点的状态。后继节点自己永远不设 SIGNAL，它只读前驱的 waitStatus 来决定是否挂起。

如果你在调试时发现某个节点的 waitStatus 长时间为 0，不要急着给它手动设 SIGNAL —— 它的前驱可能还在初始化、已被取消、或根本没走到设状态那步。真正要盯的是：它的前驱有没有成功执行 compareAndSetWaitStatus(p, 0, SIGNAL)，以及该 CAS 是否返回了 true。