ReentrantLockCondition精准线程控制方法

本文深入剖析了如何利用 ReentrantLock 配合多个 Condition 实现线程间精准、可靠的交替执行，澄清了“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 位置，或漏一次中断处理，都可能让程序在高并发下偶发卡死或乱序。

以上就是《ReentrantLockCondition精准线程控制方法》的详细内容，更多关于的资料请关注golang学习网公众号！