wait()和notify()必须在synchronized块中调用，因为JVM要求当前线程必须持有目标对象的监视器锁，否则抛出IllegalMonitorStateException；且需用while循环配合条件判断，避免虚假唤醒。
为什么 wait() 和 notify() 必须在 synchronized 块里调用
因为 JVM 要求线程必须持有对象监视器（monitor）才能执行这两个操作——不是语法限制，而是底层锁机制的硬性约定。IllegalMonitorStateException 就是 JVM 发现当前线程没锁住目标对象时抛出的。比如你写了 obj.wait()，但没用 synchronized(obj) 包裹，哪怕 obj 确实被别的线程锁着，也不行：必须是「当前线程」持有它。
常见错误写法和对应修复
下面这些代码都会触发 IllegalMonitorStateException：
- 直接调用
wait()，没加synchronized—— 最常见 - 在
synchronized(this)里调用了另一个对象的wait()，比如other.wait() - 用了
ReentrantLock而不是synchronized，然后误以为能用wait()（不能，wait()只认内置锁） - 方法声明了
synchronized，但wait()写在 if 条件外、或嵌套在 try/catch 里却漏了同步范围
修复只有一条铁律：wait()、notify()、notifyAll() 的调用点，必须落在以同一对象为锁的 synchronized 块内部。例如：
synchronized (lockObj) {
while (!conditionMet) {
lockObj.wait(); // ✅ 正确：lockObj 是当前同步块的锁
}
}
wait() 的参数和唤醒逻辑容易踩的坑
wait() 有三个重载：wait()、wait(long)、wait(long, int)。关键点不是参数本身，而是「唤醒不等于条件成立」：
立即学习“Java免费学习笔记（深入）”；
-
wait()可能被虚假唤醒（spurious wakeup），所以必须配合 while 循环判断条件，不能用 if -
notify()只唤醒一个等待线程，但无法保证唤醒的是哪个；如果多个线程等不同条件，容易错配 -
notifyAll()更安全，但可能引发“惊群”，需评估性能影响 - 传入超时时间（如
wait(5000)）后，返回时仍要检查条件，因为超时和被 notify 都会退出 wait
替代方案：什么时候不该用 wait()/notify()
这套机制原始、易错，现代 Java 多数场景建议绕开：
- 需要条件等待？优先用
java.util.concurrent工具类，比如Condition配合ReentrantLock，语义更清晰，支持多个条件队列 - 线程协作？考虑
CountDownLatch、CyclicBarrier、BlockingQueue等高级抽象 - 异步流程？
CompletableFuture或反应式库（如 Project Reactor）比手写 wait/notify 更可靠
只有当你明确控制锁对象、且必须与遗留代码或特定 JVM 行为兼容时，才碰 wait()。否则，它就像裸指针——能力很强，但一步错就崩溃。
