Condition是Lock配套的条件等待接口，支持多条件分组唤醒；而synchronized仅有一个隐式等待队列。它需通过lock.newCondition()获取，await()/signal()必须在lock()/unlock()内调用，且须用while循环检查条件以防虚假唤醒。
Condition 是什么，和 synchronized 有什么区别
Condition 是 java.util.concurrent.locks 包下的接口，必须配合 Lock（如 ReentrantLock）使用，不能替代 synchronized。它提供比 wait()/notify() 更精细的线程等待/唤醒控制——比如一个锁可以绑定多个 Condition 实例，实现「按条件分组唤醒」，而 synchronized 下每个对象只有一个隐式等待队列。
常见误用是直接 new Condition()，但它是接口，必须通过 lock.newCondition() 获取；也有人试图在 synchronized 块里调用 condition.await()，这会抛 IllegalMonitorStateException，因为 await() 要求当前线程持有对应 Lock，而非内置锁。
await() / signal() 必须成对出现在 lock() / unlock() 之间
所有 await()、signal()、signalAll() 调用都必须发生在 lock.lock() 之后、lock.unlock() 之前。否则运行时会报 IllegalMonitorStateException。
典型安全写法：
立即学习“Java免费学习笔记（深入）”；
lock.lock();
try {
while (!ready) {
condition.await(); // 等待条件成立
}
// 执行业务逻辑
} finally {
lock.unlock();
}
注意：必须用 while 判断条件，不能用 if——因为虚假唤醒（spurious wakeup）可能发生，await() 返回不保证条件真成立。
-
await()会自动释放锁，并挂起当前线程 - 被
signal()唤醒后，线程需重新竞争锁；获得锁后才从await()返回 -
signal()不释放锁，也不影响当前锁持有状态
多个 Condition 实现精准唤醒（比如生产者-消费者分离）
一个 ReentrantLock 可创建多个 Condition，例如生产者等「有空位」，消费者等「有数据」，两者互不干扰：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
private final Lock lock = new ReentrantLock(); private final Condition notFull = lock.newCondition(); private final Condition notEmpty = lock.newCondition();
当生产者发现队列满时调用 notFull.await()，消费者消费后调用 notFull.signal()；消费者发现空时调用 notEmpty.await()，生产者插入后调用 notEmpty.signal()。这样避免了 notifyAll() 带来的无差别唤醒开销。
容易忽略的点：signal() 并不保证立即唤醒——如果此时没有线程在该 Condition 上等待，这次调用就静默丢失；所以业务逻辑中不能依赖「发 signal 就一定有响应」，仍要靠循环检查条件变量。
中断敏感性：await() 可被 interrupt，signal() 不可中断
await() 有两种常用变体：await() 和 awaitUninterruptibly()。前者响应线程中断，抛 InterruptedException 并清除中断状态；后者忽略中断，直到被 signal 或虚假唤醒。
如果你的线程需要支持优雅中断（比如任务取消），应该捕获 InterruptedException 并在 finally 块中恢复中断状态或退出循环：
try {
condition.await();
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // 恢复中断标记
return; // 或抛出 RuntimeException 包装
}
signal() 和 signalAll() 本身不会抛异常，也不响应中断；它们只是向等待队列投递唤醒信号，真正处理中断的是被唤醒后重新竞争锁并返回的线程。
真正难调试的点往往不在语法，而在「谁在等、谁在唤、条件变量是否及时更新、有没有漏掉 signal」——这些错位不会立刻崩溃，而是导致死锁或线程永远挂起。
