ReentrantLockCondition精准线程控制方法

本文深入剖析了ReentrantLock中Condition机制的精准使用要点，强调其与Object.wait()/notify()的本质差异：Condition.await()必须严格配合对应ReentrantLock的显式加锁，自动释放与重入锁的闭环设计是实现线程协作精度的基础；必须用while循环防范虚假唤醒，合理选择signal()或signalAll()以匹配业务语义，善用多Condition实例实现细粒度等待队列分离；同时详解超时与中断处理的微妙区别——await()响应中断并抛异常，而带超时的方法仅返回布尔值且需二次条件检查；最后警示核心陷阱：Condition与锁强绑定于同一实例，跨锁误用将静默失效。掌握这些，才能真正发挥Condition在高并发场景下比内置监视器更可控、更灵活的线程协调能力。

Condition 的 await() 为什么不能替代 Object.wait() 那样随意用

直接调用 condition.await() 而不持有对应 ReentrantLock 的锁，会抛出 IllegalMonitorStateException。这和 Object.wait() 必须在 synchronized 块中调用是同理，但容易被忽略——因为 ReentrantLock 是显式加锁，没人帮你自动绑定。

正确姿势是：必须先 lock.lock()，再 condition.await()，且 await() 会**自动释放锁**；唤醒后重新竞争锁成功，才从 await() 返回。这个“释放→等待→重入”闭环是精准控制的前提。

• 永远把 condition.await() 放在 while 循环里检查条件，而不是 if——虚假唤醒（spurious wakeup）真实存在
• await() 返回时锁不一定已获取，它只是表示“被 signal 且已排队等待锁”，真正拿到锁要等调度器分配
• 不要在 finally 块里 unlock——await() 已释放锁，此时 unlock 会报 IllegalMonitorStateException

signal() 和 signalAll() 的选择直接影响线程唤醒精度

用 condition.signal() 只唤醒一个在该 Condition 上等待的线程；signalAll() 唤醒所有。看似简单，但误用会导致逻辑错乱或性能浪费。

比如实现“生产者-消费者”中单个空槽位就唤醒一个消费者：用 signal() 合理；但如果多个消费者都在等“有数据”，而你只 signal 一个，其余继续挂起，没问题；但若条件本身是“缓冲区非空”，却用了 signalAll()，所有消费者一起争抢，可能只有第一个能取到数据，其余又得立刻回到 while 循环判断——白唤醒。

• 优先用 signal()，除非你明确需要广播语义（如状态重置、中断全部等待者）
• 一个 ReentrantLock 可关联多个 Condition 实例，比如 notFull 和 notEmpty，各自管理不同等待队列——这是比 Object.wait()/notify() 精准得多的关键
• signal() 不保证唤醒“最早等待”的线程，JVM 不保证 FIFO，依赖公平锁（new ReentrantLock(true)）也仅影响锁竞争顺序，不影响 Condition 队列内部顺序

await() 超时与中断处理：避免永久阻塞

condition.awaitNanos(long)、awaitUntil(Date)、await(long, TimeUnit) 这些带超时的方法，返回 false 表示超时未被 signal；返回 true 表示正常被 signal 或中断。但注意：它们**不会抛 InterruptedException**，和 Thread.sleep() 不同。

而 await()（无参）和 awaitUninterruptibly() 才涉及中断语义：await() 在等待中收到中断会立即抛 InterruptedException 并清除中断状态；awaitUninterruptibly() 则忽略中断，直到被 signal 才返回——此时需手动检查 Thread.interrupted()。

• 业务逻辑中若需响应中断（如任务取消），用 await() + try-catch，别用 awaitUninterruptibly()
• 超时方法返回 false 后，仍需再次检查循环条件——超时不是失败，只是“暂未满足”，可能刚巧在超时后条件就变了
• 不要在 await() 外层 catch InterruptedException 后吞掉，至少恢复中断状态：Thread.currentThread().interrupt()

Condition 关联的锁必须是同一个 ReentrantLock 实例

常见错误：用 A 锁的 newCondition() 创建 condition，却在 B 锁的临界区里调用它的 await()。这不会编译报错，但运行时必抛 IllegalMonitorStateException，因为 Condition 内部强绑定了创建它的锁实例。

更隐蔽的问题是：多个模块各自 new 一个 ReentrantLock，然后都调 newCondition()，以为能互通——实际是完全隔离的等待队列，signal() 对另一个锁的 condition 完全无效。

• 共享 Condition 的前提是共享同一把锁实例，建议通过构造函数或 setter 注入，而非各自 new
• 调试时可打印 condition.toString()，它会包含所属锁的哈希码，方便确认是否为同一实例
• 如果需要跨多个锁协调，Condition 不适用，应考虑 Phaser、CountDownLatch 或更高层抽象如 BlockingQueue

最易被忽略的一点：Condition 的等待队列是 lock 实例私有的，哪怕两个 lock 逻辑上“应该同步”，只要不是同一个对象，signal 就永远不会抵达目标线程。

到这里，我们也就讲完了《ReentrantLockCondition精准线程控制方法》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！