wait()必须在synchronized块中调用，核心是防止丢失唤醒：确保条件检查与wait()原子执行；同时保障锁释放/重入机制、支持条件重检，并契合java monitor模型设计。
因为 wait() 方法必须由持有对象锁的线程调用，否则会抛出 IllegalMonitorStateException；更本质的原因是：防止竞态条件（尤其是“丢失唤醒”问题），确保等待条件与 wait() 调用的原子性。
防止丢失唤醒（Lost Wake-Up）
这是最核心的实际原因。假设没有同步保护：
- 消费者线程检查条件（如队列为空），结果为 true；
- 还没来得及调用
wait()，CPU 就切换到生产者线程； - 生产者完成操作并调用
notify()—— 但此时无人在等待； - 消费者线程随后才执行
wait()，永远阻塞，再也收不到通知。
这种时序错乱导致的通知丢失，就是“丢失唤醒”。加 synchronized 后，检查条件和调用 wait() 成为一个不可分割的临界区，彻底避免该问题。
保证线程持有对象锁
wait() 的语义是“释放当前持有的锁，并进入等待”。它不是无状态挂起，而是锁协作机制的一部分：
- JVM 要求调用线程必须已获得该对象的 monitor 锁（即已进入 synchronized 块/方法）；
- 只有这样，
wait()才能合法地释放锁，把线程放入该对象的等待队列（_WaitSet）； - 同理，
notify()也需持锁，才能安全地从等待队列中移出线程、放进锁竞争队列（_EntryList）。
支持条件重检与防止虚假唤醒
即使被唤醒，也不能直接认为条件已满足（可能被虚假唤醒，或多个线程竞争后条件又被改写）：
- 标准写法是
while (!condition) { obj.wait(); }，而非if； - 这个
while循环必须在同步块内——否则条件变量（如共享 flag、count）的读取和wait()之间又会出现竞态； - 只有在锁保护下读取条件、决定是否等待，才能保证逻辑一致性。
设计上与 monitor 机制深度绑定
Java 的线程通信模型基于“每个对象内置 monitor”：
- monitor 包含锁、入口队列（争锁线程）、等待队列（
wait线程）； -
wait()/notify()是 monitor 的原语操作，天然依赖锁的生命周期； - 把它们放在
Object中、强制要求同步调用，正是为了统一所有对象都可作为协调枢纽，而不是绑定到线程或特定类。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
