AQS条件队列线程转移全过程详解

本文深入剖析了AQS中Condition队列与同步队列之间线程转移的完整生命周期——从await()时线程安全地入队condition队列、彻底释放锁并退出同步队列，到signal()时精准迁移节点、CAS状态校验与同步队列入队，再到唤醒后严格遵循FIFO排队规则重新竞争锁，全程揭示了多个CAS操作、状态变更与park/unpark协同背后的严谨设计与潜在陷阱；尤其强调中断处理的特殊路径、fullyRelease失败的即时抛错，以及“迁移≠立即获锁”这一关键认知，帮你穿透表层API，真正掌握Condition底层的高并发协作逻辑。

await() 调用后线程怎么进 condition 队列

调用 Condition.await() 的前提是当前线程已持有锁（即已进入 AQS 同步队列并成功获取 state），所以插入等待节点时无需 CAS 竞争——addConditionWaiter() 直接链表尾插，靠锁的排他性保障线程安全。

这个过程会做三件事：

• 新建一个 Node，类型为 Node.CONDITION，waitStatus = Node.CONDITION
• 把该节点追加到 condition 队列尾部（lastWaiter 指针更新）
• 若原尾节点已取消（waitStatus != Node.CONDITION），则先遍历清理所有取消节点再插入

fullyRelease() 释放锁时同步队列发生了什么

await() 紧接着调用 fullyRelease(node)，它本质是调用子类实现的 tryRelease(1) 尝试将 state 减到 0；成功后，会唤醒同步队列中 head 的后继节点（如果存在且状态正常）。

关键点在于：此时当前线程已彻底脱离同步队列 —— 它的 Node 不在同步队列里了，也不再参与锁竞争。但注意：fullyRelease() 失败（比如重入锁未完全释放）会直接抛 IllegalMonitorStateException，await() 根本不会继续往下走。

signal() 唤醒时如何把节点从 condition 队列移到同步队列

signal() 不是直接 unpark，而是执行「迁移」：把 condition 队列头节点（firstWaiter）摘下，通过 transferForSignal(node) 尝试将其加入同步队列尾部。

这个迁移不是无条件成功的：

• 先用 CAS 将 node 的 waitStatus 从 CONDITION 改为 0（初始同步节点状态）；失败说明该节点已被 cancel 或 signal 过，跳过
• CAS 成功后，调用 enq(node) 插入同步队列——这里必须用自旋 + CAS，因为同步队列是多线程竞争的
• 插入成功后，才调用 LockSupport.unpark(node.thread)；但此时线程还没醒，它刚进同步队列，要等前驱节点变成 head 并调用 tryAcquire() 才可能真正获取锁返回

被唤醒后线程怎么重新竞争锁并返回 await()

线程被 unpark 后，从 LockSupport.park(this) 返回，进入 acquireQueued() 流程：检查前驱是否为 head、尝试 tryAcquire()、失败则再次 park……直到获取锁成功。

但注意两个易忽略细节：

• 如果线程是被中断唤醒（非 signal()），checkInterruptWhileWaiting() 会返回 REINTERRUPT 或 THROW_IE，最终在 await() 末尾抛 InterruptedException 或自我中断，**不会**进入同步队列竞争锁
• 即使成功迁移到同步队列，也不代表马上能获取锁——它只是获得了“排队资格”，仍要按 FIFO 等待前驱节点释放，这点和 Object.wait() 唤醒后立即参与锁竞争有本质区别

整个迁移过程没有“一步到位”的原子指令；它是靠多个 CAS 操作（condition 队列清理、waitStatus 修改、同步队列插入）+ 锁状态变更 + park/unpark 协同完成的，任一环节失败都会导致节点滞留或丢弃。真正容易出错的地方，往往不在 signal，而在 await 释放锁失败、或中断处理路径没走对。

终于介绍完啦！小伙伴们，这篇关于《AQS条件队列线程转移全过程详解》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！