Condition 的 await()/signal() 唤醒的是等待队列头部任意线程而非指定线程；交替执行靠多个Condition分离等待逻辑、while循环严格检查条件、修改状态后signal，且需正确处理中断。
Condition 的 await() / signal() 不是“唤醒指定线程”，而是“唤醒等待在该 Condition 上的任意一个线程”
这是最常被误解的一点：很多人以为 signal() 能像信号量那样精准唤醒某个特定线程，其实它只唤醒等待队列头部的一个线程（FIFO），且无法指定目标。真正实现“交替执行”的关键不是靠 signal() 选人，而是靠每个线程在 await() 前严格检查自己的执行条件（用 while 循环 + 条件变量），靠多个 Condition 实例分隔不同等待逻辑。
比如两个线程交替打印 A/B，你需要两个 Condition：printACondition 和 printBCondition，分别对应“轮到 A 打印”和“轮到 B 打印”两种状态；线程只有在条件不满足时才 await()，满足时才执行并 signal() 下一个。
必须用 while 而不是 if 包裹 await()，否则会丢失唤醒或虚假唤醒
await() 可能因虚假唤醒（spurious wakeup）或被中断而提前返回，如果只用 if (condition) await();，线程醒来后直接执行后续逻辑，很可能违反业务约束。正确写法是：
while (!shouldPrintA()) {
printACondition.await();
}
其中 shouldPrintA() 是基于共享状态（如 volatile int turn = 0）的判断逻辑。常见错误包括：
- 用
if替代while，导致多唤醒一次就乱序 - 把条件判断写在
lock()外面，造成竞态（判断和 await 之间状态被改） - 忘记在每次 signal 后更新共享状态（例如
turn = 1），导致下一个线程永远等下去
ReentrantLock 配合多个 Condition 实现交替的核心模板
以两个线程交替打印为例，核心结构如下：
private final ReentrantLock lock = new ReentrantLock();
private final Condition printACondition = lock.newCondition();
private final Condition printBCondition = lock.newCondition();
private volatile int turn = 0; // 0: A, 1: B
// 线程 A
lock.lock();
try {
while (turn != 0) {
printACondition.await();
}
System.out.print("A");
turn = 1;
printBCondition.signal(); // 唤醒 B，不是“叫 B”，而是“通知 B 可以检查自己是否该执行了”
} finally {
lock.unlock();
}
注意几点：
- 每个
Condition对应一种等待意图，不要混用 -
signal()必须在修改完共享状态（turn = 1）之后调用，否则 B 醒来检查时条件仍为 false，又 await 回去 - 如果要用三个及以上线程交替（如 A→B→C→A），就建三个
Condition，状态用取模或枚举控制 -
signalAll()在交替场景中通常没必要，反而可能引发多个线程争抢、需重新 await
容易被忽略的锁释放时机与中断处理
await() 会自动释放锁，并在被唤醒/中断后重新获取锁——这个“重入”过程是原子的，但如果你没处理中断，线程可能带着 InterruptedException 退出，导致后续 signal() 没执行，整个链路卡死。
稳妥做法是：
- 捕获
InterruptedException，在 finally 块中恢复中断状态（Thread.currentThread().interrupt()） - 不要在
await()外层吞掉异常却不恢复中断，否则上层无法感知取消意图 - 避免在
await()期间持有其他锁或做耗时操作，因为 await 期间锁已释放，状态可能被并发修改
真正难的不是写对一两次交替，而是让状态更新、条件检查、signal 顺序、中断响应全部咬合严丝合缝——少一个 while，错一次 signal 位置，或漏一次中断处理，都可能让程序在高并发下偶发卡死或乱序。
