JavaCondition精准唤醒线程教程

本文深入剖析了Java中Condition接口实现线程精准唤醒的核心机制与常见陷阱，重点揭示了await()不唤醒的真正原因并非语法错误，而是signal()/signalAll()调用未严格满足“同Lock、同Condition、持锁执行”三大前提；同时对比Object.wait()阐明Condition支持单锁多等待队列的独特优势，使生产者-消费者等场景能按条件精确唤醒对应线程，避免无效通知和虚假唤醒；更关键的是指出“唤醒后卡住”的本质是await返回前需重新竞争锁，而非唤醒失效——这要求开发者跳出synchronized思维定式，严谨把控锁的获取、释放时机与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学习网公众号，带你了解更多关于的知识点！