wait和notify必须在synchronized块中调用，否则抛IllegalMonitorStateException；wait释放锁并挂起线程，notify仅标记唤醒，不释放锁；需用while循环校验条件防虚假唤醒；notify随机唤醒一个线程，notifyAll唤醒所有；LockSupport和Condition提供更灵活安全的替代方案。
wait 和 notify 必须在 synchronized 块里调用
否则会抛出 IllegalMonitorStateException。这是因为 wait 和 notify 操作依赖当前线程是否持有对象的 monitor 锁——只有进入 synchronized 块（或方法）后，线程才真正“拥有”该锁，才能安全地释放（wait）或唤醒（notify）其他等待者。
常见错误写法：
obj.wait(); // ❌ 没有同步上下文
正确写法：
synchronized (obj) {
obj.wait();
}
-
wait()会释放锁并挂起当前线程，直到被notify()或notifyAll()唤醒，或超时（如果带参数） -
notify()不会立即释放锁，只是标记一个等待线程为“可唤醒”，它仍需等当前 synchronized 块退出后，被唤醒线程才能重新竞争锁 - 不要假设
notify()一定唤醒“最久等待”的线程——JVM 不保证唤醒顺序，也不保证唤醒哪个
为什么 wait 要放在 while 循环里而不是 if
虚假唤醒（spurious wakeup）是真实存在的：线程可能在没有被 notify 的情况下自行醒来。如果不检查条件，就会跳过本该等待的状态，导致逻辑错误。
立即学习“Java免费学习笔记（深入）”；
典型模式：
synchronized (lock) {
while (!conditionMet) {
lock.wait();
}
// 执行业务逻辑
}
- 用
while而不是if，确保每次醒来都重新校验条件 - 条件变量（如队列是否为空、资源是否就绪）必须是共享且 volatile 或受同一锁保护的，否则可能读到过期值
-
notify()后不重置条件？那被唤醒的线程一进循环就又wait()回去了——这是正常行为，不是 bug
notify 和 notifyAll 的选择取决于等待者语义
二者都只在 synchronized 块内有效，区别在于唤醒范围：
-
notify()随机唤醒**一个**在该对象上wait的线程；适合“点对点”场景，比如生产者-消费者中，一个产品入队后只需唤醒一个消费者 -
notifyAll()唤醒**所有**等待线程；适合“广播”场景，比如状态变更影响多个监听者（如关闭标志位、配置重载） - 误用
notify()可能导致死锁：若唤醒的线程发现条件不满足又回去wait，而真正需要唤醒的线程一直没被选中 - 性能上
notifyAll()开销略大，但现代 JVM 对空等待集做了优化，不必过度担心
wait/notify 无法跨对象协作，替代方案要考虑 LockSupport
wait 和 notify 是对象级别的，只能用于同一 Object 实例上的线程通信。如果你需要更灵活的控制（比如指定唤醒某个线程、支持中断、无锁等待），LockSupport 是底层更直接的选择。
-
LockSupport.park()和unpark(Thread)不要求锁，也不抛IllegalMonitorStateException - 但
park不自动释放任何锁，需手动管理同步；也缺乏内置条件判断机制，容易写错唤醒时机 -
java.util.concurrent中的Condition（配合ReentrantLock）才是高级封装：它把“等待条件”和“唤醒策略”解耦，支持多个Condition实例对应同一锁，比原生wait/notify更安全可控
真正难的不是调用这两个方法，而是设计清楚谁负责通知、何时通知、被通知者是否一定能收到且不漏判——这些靠 API 本身不解决，得靠状态建模和边界测试来兜住。
