wait/notify 必须在 synchronized 块中调用，因为 jvm 要求线程持有对象锁才能执行，以保障释放锁、入队、条件检查、信号传递和防止虚假唤醒等操作的原子性与正确性。
因为 JVM 强制要求调用 wait 或 notify 的线程必须是目标对象的监视器锁持有者，否则直接抛出 IllegalMonitorStateException。这不是语法限制，而是保障线程协作正确性的底层机制。
wait 本质是“释放锁 + 进入等待队列”的原子操作
调用 wait() 不只是暂停线程，它必须同时完成两件事：
- 释放当前持有的对象监视器锁（即 synchronized 锁）
- 将当前线程挂起，并加入该对象的等待队列（wait set）
这两个动作必须原子执行，而只有先获得锁，JVM 才知道该释放哪个锁、往哪个等待队列放线程。没拿锁就调 wait()，等于让线程“释放一个不存在的东西”，逻辑不成立。
条件检查和等待必须在锁保护下保持原子性
真实场景中，wait 总是跟着一个条件判断，比如“缓冲区为空才等待”。这个判断和后续的 wait() 必须在同一个锁内完成，否则会出现竞态：
- 线程 A 判断缓冲区为空 → 准备 wait
- 线程 B 此时插入数据并调用
notify() - 线程 A 还没来得及
wait()，信号就丢失了
加 synchronized 后，整个“检查条件 → 决定是否 wait”过程被锁串行化，避免信号丢失。
notify 需要锁来完成“移交控制权”的语义
notify() 的作用不是立刻唤醒线程并让它执行，而是把等待队列中的一个线程移到该对象的入口队列（entry set），让它和其他线程一起竞争锁。这个转移动作本身需要由当前持有锁的线程发起，否则无法保证目标线程能安全地重新获取锁并继续执行。
换句话说：没有锁，notify() 就不知道该把谁“交还给谁”，也无法确保被唤醒的线程能立即看到最新的共享状态。
防止虚假唤醒导致逻辑错误
即使没有其他线程调用 notify()，JVM 也可能随机唤醒等待线程（spurious wakeup）。所以正确写法永远是：
while (!条件成立) { obj.wait(); }
这个 while 循环必须在 synchronized 块内——只有重新拿到锁，才能再次安全读取共享变量（如缓冲区大小、标志位等），确认条件是否真的满足。脱离锁的条件检查，读到的可能是过期值。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
