await()后线程进入condition队列：先新建CONDITION节点尾插，清理取消节点，再通过fullyRelease()释放锁并退出同步队列；signal()时迁移头节点至同步队列，CAS修改waitStatus后enq插入，再unpark；唤醒后需重新排队竞争锁，中断则不参与竞争。
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 释放锁失败、或中断处理路径没走对。
