Condition必须与ReentrantLock配对使用，通过lock.newCondition()获取，绑定于特定锁实例；await()前须持有对应锁，会自动释放并挂起线程，唤醒后需重新竞争锁；需用while循环重检条件，配合try-finally确保unlock，signal()和signalAll()选择取决于等待条件是否互斥。
Condition 必须和 ReentrantLock 配对用，不能单独 new
Condition 不是独立的同步工具，它只是 ReentrantLock 的“附属唤醒通道”。直接 new Condition() 会编译失败——它没有公共构造器。你只能通过 lock.newCondition() 获取，而且每个 Condition 实例都绑定到创建它的那个 ReentrantLock 实例上。
常见错误现象：IllegalMonitorStateException 抛出，不是因为没加锁，而是调用 condition.await() 前没用对应 lock 的 lock.lock()；或者用 A 锁创建的 condition，却在 B 锁的临界区里 await。
- 必须先
lock.lock()，再调用condition.await() -
await()会自动释放当前线程持有的该 lock，并挂起线程 - 被
signal()唤醒后，线程需重新竞争该 lock，获取成功才继续执行 - 一个
ReentrantLock可以创建多个Condition，实现不同等待队列（比如“生产者队列”和“消费者队列”）
await() 和 signal() 必须在 try-finally 里配对保护
看似简单的等待-唤醒，实际极易因异常跳过 unlock 导致死锁。Java 不像 synchronized 那样自动释放锁，ReentrantLock 的释放完全手动控制。
使用场景：网络 IO 超时、计算过程抛异常、业务逻辑提前 return——任何跳出临界区的路径，都必须确保 lock.unlock() 执行。
立即学习“Java免费学习笔记（深入）”；
-
await()前必须已持有 lock，且之后会自动释放；但唤醒返回后要自己 re-acquire，所以解锁动作只发生在进入 await 时 -
signal()不要求当前线程持有 lock？错！它必须在 lock 保护下调用，否则抛IllegalMonitorStateException - 标准写法：在
try块里 await，在finally里 unlock —— 即使 await 被中断或超时，lock 也得放掉
signal() vs signalAll()：唤醒一个还是全部？看等待条件是否互斥
这不是性能问题，是逻辑正确性问题。signal() 只唤醒一个在该 Condition 上 await 的线程，但不保证唤醒谁；signalAll() 唤醒所有。选错可能造成永久阻塞或虚假唤醒漏判。
典型反例：一个 Condition 对应多个不同等待条件（比如“缓冲区非空”和“缓冲区未满”混用同一个 condition），此时用 signal() 可能唤醒错类型的线程，它醒来检查发现条件仍不满足，又回去 await——而真正该醒的线程一直没被 signal。
- 如果所有 await 线程等待的是同一类条件（例如都是等“有新任务”），用
signal()安全且高效 - 如果等待条件存在歧义（比如生产者和消费者共用一个 condition），必须用
signalAll()，并让每个线程 await 后用 while 循环重检条件 - 永远不要用 if + await，要用 while + await：防止虚假唤醒或条件被其他线程抢走
Condition.await(long, TimeUnit) 的超时不是“最多等这么久”
这个方法看起来像设了上限，但实际行为更微妙：它会在指定时间内等待，但如果被中断或发生虚假唤醒，也会提前返回 false。返回值 false 并不等于“超时”，而只是“没被正常 signal 就醒了”。很多代码误把 false 当成超时信号，忽略重检条件，导致逻辑错乱。
性能影响：超时 await 内部依赖系统纳秒精度计时，频繁调用小粒度超时（如 1ms）会增加内核态开销；兼容性上，Windows 和 Linux 对纳秒级定时的实现略有差异，极端情况下误差可达几毫秒。
- 返回
false时，必须再次检查业务条件是否成立，不能直接当作“超时失败”处理 - 若需严格超时控制（比如“最多等 500ms，过期就放弃”），应在 while 循环外维护绝对截止时间，每次 await 前计算剩余时间
- 避免
await(0, TimeUnit.NANOSECONDS)这种写法——它等价于无等待的虚假唤醒检查，意义不大还多一次系统调用
Condition 的精准在于“按队列唤醒”，但精准的前提是队列划分清晰、条件检查严谨、锁生命周期可控。最容易被忽略的，是把 await() 当作普通阻塞函数来用，忘了它背后那套 lock 释放-重入-重检的完整契约。
