Condition.await() 线程不唤醒的根本原因是未在同Lock实例的Condition上调用signal()/signalAll()，且signal()必须在持锁状态下执行；await()返回前需重新获取锁，唤醒后可能因锁竞争而阻塞。
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 实例，尤其是静态缓存或单例管理时。
立即学习“Java免费学习笔记（深入）”；
- 不要把
Condition当成全局资源长期持有 —— 它不是线程安全的“服务”，而是锁的附属品 - 同一个
Condition可被多个线程并发 await，没问题；但不要在不同Lock实例上复用同一个Condition（编译不过） - 如果 Lock 是可重入的，
Condition.await()会一次性释放全部重入计数，唤醒时再一次性恢复，这点和 Object.wait() 不同 - 别用
==比较两个Condition是否“相同”——它们是不同对象，即使来自同一个 lock
Condition 的精准性只在“多条件分离”时才体现价值；如果所有线程都用同一个 condition，那和 signalAll() 没本质区别。最容易忽略的是：await 返回不等于业务逻辑可执行，中间隔着一把锁的争夺。
