Condition.await() 总被唤醒却没收到信号的根本原因是它只响应同一锁下对应Condition的signal()或signalAll()，且提前signal()会导致信号丢失；必须用while循环检查条件、每个语义独立场景配专属Condition、signal()不唤醒其他Condition的线程、唤醒前需确认线程已进入await()。
Condition.await() 为什么总被唤醒却没收到信号
根本原因不是 await() 有问题，而是它只响应对应 Condition.signal() 或 signalAll()，且必须在同一个锁下操作。常见错误是：用 ReentrantLock 创建了多个 Condition，但唤醒时用了错的对象，或者线程还没进入 await() 就提前 signal() —— 这个信号直接丢失，不会排队等待。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 每个业务语义独立的等待场景，配一个专属
Condition，比如「库存充足」和「订单已支付」不能共用一个Condition - 唤醒前务必确认目标线程已执行到
await()，否则信号丢弃；可加日志或用Thread.getState()辅助判断（仅调试） - 避免在循环外调用
await()，正确写法是while (!conditionMet) { condition.await(); }，防止虚假唤醒
ReentrantLock.newCondition() 创建的 Condition 不共享
同一个 ReentrantLock 实例调用多次 newCondition()，会返回互不干扰的 Condition 对象。它们各自维护独立的等待队列，signal() 只唤醒自己队列里的线程。这点和 synchronized + wait()/notify() 的单等待队列模型完全不同。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 不要误以为
conditionA.signal()能唤醒在conditionB.await()中等待的线程——不可能，连编译都不报错，但逻辑永远走不通 - 如果需要“广播给所有条件”，得手动对每个
Condition调用signalAll()，而不是指望一个通用唤醒机制 - 命名要直白，比如
inventoryAvailable、paymentConfirmed，避免用cond1、cond2这类变量名，后期维护极易出错
signal() 和 signalAll() 的性能与唤醒精度差异
signal() 只唤醒等待队列头部的一个线程，适合“一个资源就绪，只够一人用”的场景；signalAll() 唤醒全部，适合“状态变更影响所有人”的情况。但后者代价高：所有被唤醒线程都要重新竞争锁，再检查条件是否真满足，容易引发惊群效应。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 优先用
signal()，尤其在生产者-消费者中，一个新元素通常只够唤醒一个消费者 - 只有当条件变化可能让多个等待者同时满足时才用
signalAll()，例如：缓存失效后所有等待读取旧值的线程都该重试 - 注意 JVM 实现细节：
signal()不保证唤醒“最先等待”的线程，只是从队列头取一个，具体顺序依赖底层队列实现，别依赖 FIFO 做逻辑假设
Condition 在 try-finally 中释放锁的典型漏写
很多人只记得在 await() 前加 lock.lock()，却忘了 await() 本身会自动释放锁，而唤醒后线程恢复执行时，锁已被重新获取——所以后续代码不需要再 lock()，但 unlock() 必须放在 finally 块里，且只针对非 await 流程的路径。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 标准模板是：
lock.lock(); try { while (!ready) { condition.await(); } /* 处理逻辑 */ } finally { lock.unlock(); } - 千万别把
await()包进try后还写unlock()——await()已经释放锁，此时 unlock 会抛IllegalMonitorStateException - 如果逻辑里存在提前 return 或异常分支，确保所有出口都覆盖在
finally的锁释放范围内，否则锁泄露，系统逐步卡死
Condition 的精准性全靠开发者自己维护“谁等什么、谁该被谁唤醒”这层映射关系。没有反射、没有自动绑定、不校验语义，写错就静默失效。最容易被忽略的是：唤醒时机和等待条件检查的耦合度——它不像数据库事务有回滚点，一步错，整条线程就挂在那里，既不报错也不推进。
