登录
首页 >  文章 >  java教程

AQSSIGNAL状态详解与作用分析

时间:2026-05-06 15:00:56 437浏览 收藏

SIGNAL状态在AQS中并非表示“当前节点等待被唤醒”,而是前驱节点对后继节点作出的明确承诺——“我释放锁时必定唤醒你”,这一关键契约决定了SIGNAL只能由已就绪的前驱节点在挂起自身前通过CAS安全设置,后继节点既无权也无力自行设定;理解这一设计能避免常见误操作(如在enq中提前设SIGNAL导致CAS失败或逻辑混乱),厘清AQS唤醒机制的本质是责任委托而非被动等待,从而真正掌握同步队列中线程挂起与唤醒的精准协作逻辑。

如何通过 AQS 的 SIGNAL 状态位理解后继线程在入队前为何需要前驱线程通过 CAS 进行显式标记

为什么 SIGNAL 必须由前驱节点设置,而不是后继自己设

因为 SIGNAL 的语义是“我释放锁时,必须 unpark 我的后继”,这个责任只能由前驱节点承担——后继线程还没入队完成、甚至还没构造好 Node,根本无法安全地给自己或别人设状态。

常见错误现象:有人试图在 enq() 中让新节点一入队就 compareAndSetWaitStatus(this, 0, SIGNAL),结果要么 CAS 失败(前驱还没来得及更新),要么逻辑错乱(此时前驱可能还是 head,而 headwaitStatus 本不该是 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 == CONDITIONPROPAGATE:说明前驱不在同步队列主路径上,当前线程需重新评估排队位置

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

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

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

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

到这里,我们也就讲完了《AQSSIGNAL状态详解与作用分析》的内容了。个人认为,基础知识的学习和巩固,是为了更好的将其运用到项目中,欢迎关注golang学习网公众号,带你了解更多关于的知识点!

资料下载
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>