condition 是 java 并发中实现线程精准协作的关键工具，通过与 lock 绑定提供多等待队列、语义明确的唤醒机制，并需满足锁内调用、while 循环校验、状态先变、finally 解锁四前提。
Condition 是 Java 并发编程中实现线程精准协作的关键工具，它不是简单替代 wait/notify，而是通过与 Lock 深度绑定，提供可拆分、可复用、多队列的等待/通知能力，真正解决复杂同步场景下的唤醒粒度和条件耦合问题。
Condition 的核心价值：不止是“换种写法”
传统 synchronized + wait/notify 的最大限制在于：每个对象只有一个隐式等待队列，所有线程共用同一组条件判断逻辑。一旦多个业务条件（如“缓冲区满”和“缓冲区空”）混在同一队列里，signal() 就可能唤醒错误类型的线程，造成无效唤醒或遗漏。
Condition 的突破在于——一个 Lock 可创建多个 Condition 实例，每个 Condition 独立维护自己的等待队列。比如生产者-消费者模型中：
- notFull：专供生产者等待“有空位”，只被消费者 take 后 signal
- notEmpty：专供消费者等待“有数据”，只被生产者 put 后 signal
这种分离让唤醒行为具备语义明确性，避免了 notifyAll() 的粗暴广播和虚假唤醒的连锁风险。
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
正确使用 Condition 的四个硬性前提
Condition 不是“拿来即用”的工具，它的行为严格依赖执行上下文。以下四点任一缺失都可能导致死锁、IllegalMonitorStateException 或静默失效：
- 必须在持有对应 Lock 的前提下调用 await()、signal() 或 signalAll()
- await() 必须包裹在 while 循环中检查条件，不能用 if（防止虚假唤醒）
- signal() 前必须确保条件已真实改变（例如 count++ 后再 notEmpty.signal()）
- Lock 的 lock()/unlock() 必须成对出现在 try-finally 中，确保异常时仍能释放锁
比 Object 方法更实用的高级能力
Condition 提供了 wait/notify 所不具备的可控性，尤其在健壮性和调试友好性上优势明显：
- 超时等待：await(5, TimeUnit.SECONDS) 可避免线程无限挂起，适合网络响应、资源探活等场景
- 中断感知：await() 响应 interrupt() 并抛出 InterruptedException，便于上层做取消处理
- 无中断等待：awaitUninterruptibly() 适用于关键清理阶段，确保不被外部打断
- 精确唤醒控制：signal() 唤醒单个线程，signalAll() 唤醒全部；可根据负载选择，避免惊群效应
典型误用与规避建议
实际开发中最常踩的坑，往往源于对 Condition 生命周期和线程状态理解偏差：
- 在未获取锁时调用 await() → 抛出 IllegalMonitorStateException
- 用 if 替代 while 判断条件 → 虚假唤醒后直接跳过检查，导致逻辑错乱（如向已满缓冲区继续写入）
- signal() 后未修改共享状态 → 唤醒的线程再次 await，陷入循环等待
- 多个 Condition 共享同一把锁但未隔离等待逻辑 → 本该唤醒 A 队列的 signal() 错误触发 B 队列线程
只要守住“锁内操作、循环校验、状态先行、finally 解锁”这十六字原则，Condition 就能稳定支撑高并发下的精细协作。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
