JavaCondition接口：线程精准唤醒操作详解

Java中的Condition接口是ReentrantLock实现线程精准唤醒的核心机制，它通过一个锁绑定多个等待队列（如“非空”“非满”独立Condition），彻底摆脱了Object.wait()/notify()的粗粒度通知缺陷；但其正确使用高度依赖“同锁同Condition+持锁调用signal+及时释放锁”这一铁三角规则——常见失效并非await写错，而是signal未在加锁后调用、跨Condition误用或唤醒后因锁竞争而卡在重入获取阶段，真正掌握它，才能在高并发场景中实现高效、可控的线程协作。

Condition.await() 为什么线程不唤醒？

根本原因不是 await() 写错了，而是没配对用 signal() 或 signalAll()，且必须在同一个 Lock 实例关联的 Condition 上操作。常见错误是：用 synchronized + wait() 的思维写 ReentrantLock + Condition，结果调用 signal() 前没先获取锁，或者在不同 Condition 实例上调用。

• 必须先 lock.lock()，再调用 condition.await()；否则抛 IllegalMonitorStateException
• signal() 也必须在持锁状态下调用，否则无效（不报错但不唤醒）
• 一个 ReentrantLock 可创建多个 Condition，但 signal() 只唤醒该 Condition 上等待的线程，别指望它“跨条件”唤醒
• 如果用 newCondition() 多次，得到的是不同对象，c1.signal() 对 c2.await() 中的线程完全没影响

Condition 和 Object.wait() 的关键区别在哪？

最实际的区别是：Object 的 wait() 只能绑定到一个隐式监视器（即 synchronized 锁对象），而 Condition 允许一个锁配多个等待队列——这才是“精准唤醒”的来源。比如生产者-消费者场景中，你可以为“队列非空”和“队列非满”各建一个 Condition，避免虚假唤醒或无差别通知。

• Object.wait() 调用后自动释放当前 synchronized 锁；Condition.await() 释放的是关联的 Lock，不是任意锁
• await() 返回前会重新获取锁，而 wait() 被唤醒后只是“进入锁竞争队列”，不保证立刻执行
• Condition 支持带超时的 awaitNanos(long)、awaitUntil(Date)，Object.wait() 超时精度受 JVM 实现影响更大
• 没有 notifyAll() 等价物叫 notifyAll() —— 它就叫 signalAll()，别拼错

signal() 后线程为什么还没执行？

不是没唤醒，是唤醒后还在等锁。因为 await() 返回前必须重新获得关联的 Lock，如果此时有其他线程正持有该锁（比如 signal() 刚释放锁，另一个线程抢到了），那被唤醒的线程就得排队等锁，表现为“醒了但卡住”。这是最常被误判为“唤醒失效”的地方。

• 检查是否在 signal() 后立刻 unlock() —— 如果没释放锁，被唤醒线程永远拿不到锁，也就卡死在 await 返回前
• 避免在 signal() 和 unlock() 之间做耗时操作，否则延长了唤醒线程的等待时间
• 不要假设 signal() 后下一行代码就是被唤醒线程执行的 —— 它可能要等几毫秒甚至更久才能真正 resume
• 调试时可在 await() 前后加日志，确认是否进了 await、是否返回，再结合锁状态判断卡点

ReentrantLock.newCondition() 的生命周期要注意什么？

Condition 实例本身无状态，但它的行为完全依赖所绑定的 Lock 实例。一旦 Lock 被 GC 或不再使用，对应 Condition 就失去意义；更危险的是复用已废弃的 Condition 实例，尤其是静态缓存或单例管理时。

• 不要把 Condition 当成全局资源长期持有 —— 它不是线程安全的“服务”，而是锁的附属品
• 同一个 Condition 可被多个线程并发 await，没问题；但不要在不同 Lock 实例上复用同一个 Condition（编译不过）
• 如果 Lock 是可重入的，Condition.await() 会一次性释放全部重入计数，唤醒时再一次性恢复，这点和 Object.wait() 不同
• 别用 == 比较两个 Condition 是否“相同”——它们是不同对象，即使来自同一个 lock

Condition 的精准性只在“多条件分离”时才体现价值；如果所有线程都用同一个 condition，那和 signalAll() 没本质区别。最容易忽略的是：await 返回不等于业务逻辑可执行，中间隔着一把锁的争夺。

今天关于《JavaCondition接口：线程精准唤醒操作详解》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！