SIGNAL必须由前驱节点设置，因为其语义是“我释放锁时必唤醒后继”，该责任只能由已就绪的前驱承担；后继入队未完成，无法安全自设，且AQS中仅前驱在park前通过shouldParkAfterFailedAcquire中的CAS设置SIGNAL。
为什么 SIGNAL 必须由前驱节点设置，而不是后继自己设
因为 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。
