await()前必须先获取锁，否则抛IllegalMonitorStateException；addConditionWaiter()将节点以Node.CONDITION状态加入单向condition队列并清理无效节点；fullyRelease()彻底释放锁并将节点移出同步队列；signal()通过CAS修改waitStatus后调用enq()将节点迁入双向同步队列；被唤醒后检查是否在同步队列，再走acquireQueued流程重新竞争锁。
await() 调用后线程怎么进 Condition 队列
线程必须先持有锁（即已在 AQS 同步队列中成功 acquire），否则 await() 会直接抛 IllegalMonitorStateException。这不是“可能出错”，而是调用前提——没 lock 就 await，代码立刻崩。
真正入队动作在 addConditionWaiter()：新建一个 Node，waitStatus = Node.CONDITION，然后单向链表尾插到 ConditionObject 的 lastWaiter。这个过程不走 CAS，因为调用时锁已被当前线程独占，天然串行。
但插入前会清理：如果原 lastWaiter 的 waitStatus != Node.CONDITION（比如已被 cancel），就遍历整个 condition 链表，把所有非 CONDITION 节点全干掉。这一步容易被忽略，但它决定了后续 signal() 是否能拿到有效的头节点。
fullyRelease() 释放锁时同步队列发生了什么
fullyRelease(node) 不是“暂时让出”，而是把当前线程持有的全部 state 归零（比如可重入锁的全部重入次数）。它调用子类实现的 tryRelease(1)，失败就直接抛异常，await() 根本不会继续往下走。
关键影响是：该线程的 Node 此刻已从同步队列中彻底移除——它不再参与任何锁竞争，也不再是同步队列的一部分。同时，head 的后继节点（如果存在且状态正常）会被唤醒，去尝试获取锁。
常见误判：以为线程还在同步队列里“挂着等 signal”。实际它已经“消失”了，condition 队列和同步队列此时是两个完全独立的链表，物理上无交集。
signal() 怎么把节点从 Condition 队列移到同步队列
signal() 不直接 unpark，只做迁移：transferForSignal(node) 先用 CAS 把节点的 waitStatus 从 Node.CONDITION 改为 0；失败说明该节点已被 cancel 或已被其他线程 signal 过，直接跳过。
CAS 成功后，调用 enq(node) 把该节点插入同步队列尾部。注意：enq() 是自旋 + CAS 实现的，因为同步队列是多线程竞争的，而 condition 队列不是。
插入成功才调用 LockSupport.unpark(node.thread)。但此时线程还没醒——它刚进同步队列，得等前驱变成 head、且 tryAcquire() 成功，才能真正返回 await()。
被唤醒后线程怎么重新竞争锁并返回 await()
线程从 LockSupport.park(this) 返回后，第一件事是调用 isOnSyncQueue(node) 检查自己是否已在同步队列中。这个判断靠的是节点的 prev 是否为 null，或 waitStatus 是否为 Node.CONDITION ——不是查 condition 队列有没有它，而是看它是不是已经被迁过去了。
确认在同步队列后，进入 acquireQueued(node, savedState) 流程：检查前驱是否为 head、尝试 tryAcquire()、失败则再次 park……直到获取锁成功。
中断是个特例：如果线程在 park 中被中断，checkInterruptWhileWaiting() 会返回 THROW_IE 或 REINTERRUPT，然后直接进 acquireQueued()。这意味着中断 ≈ 隐式 signal，但它绕过了 condition 队列头部，由当前线程自己触发迁移——这也是为什么中断后仍需重新 acquire：锁还被别人占着。
最易忽略的一点：condition 队列是单向链表，同步队列是双向链表；迁移不是复制节点，而是复用同一个 Node 实例，仅修改其 waitStatus 和前后指针。节点身份没变，只是“户口”从一个队列迁到了另一个。
