为什么 wait() / notify() 必须在同步代码块 / 同步方法中调用
目录
一、先搞懂基础
二、核心原因（3 点）
1. 防止 丢失唤醒（Lost Wake-Up）（最关键）
错误时序（无锁场景）
加锁后（同步块），时序被原子化
2. JVM 语法强制：必须持有对象监视器
3. 保证等待 / 唤醒逻辑的线程安全
三、补充最佳实践（面试常考）
面试极简背诵版
一句话结论：为了规避「丢失唤醒」并发 bug，同时保证线程安全、语义合法，JVM 强制要求必须持有对象锁才能调用。
一、先搞懂基础
wait()、notify()、notifyAll()是Object 类方法，作用于对象监视器（锁）。- 调用
obj.wait()：当前线程释放 obj 锁，进入该对象的等待集阻塞，等待被唤醒。 - 调用
obj.notify()：随机唤醒等待集中一个线程；notifyAll()唤醒全部。
二、核心原因（3 点）
1. 防止丢失唤醒（Lost Wake-Up）（最关键）
这是设计层面的根本原因，先看不在同步块会出现的致命问题：
错误时序（无锁场景）
假设业务逻辑：条件不满足 → 等待；条件满足 → 唤醒
- 线程 A：判断
条件不成立，正要执行wait() - CPU 切换到线程 B
- 线程 B：修改数据，
条件成立，执行notify()唤醒 →此时线程 A 还没进入等待队列，这次唤醒直接作废 - CPU 切回线程 A：继续执行
wait()→ 线程 A 永久阻塞，永远没人再唤醒它（丢失唤醒）
加锁后（同步块），时序被原子化
锁保证「条件判断 + wait ()」是原子操作：
- 线程 A 获取锁 → 判断条件不成立
- 直接执行
wait()（原子完成，中间不会被打断） - 线程 B 必须等 A 释放锁后才能进入、修改条件、notify 彻底杜绝「先唤醒、后等待」的丢失唤醒问题。
2. JVM 语法强制：必须持有对象监视器
JVM 规范规定：
调用
wait()/notify()时，当前线程必须持有该 Object 的内置锁。
如果没有持有锁直接调用，会立刻抛出：
java.lang.IllegalMonitorStateException原因：
wait()语义是 **“拿着锁，主动放弃锁并等待”**；- 没有锁，就不存在「放弃锁」这个动作，语义不成立。
3. 保证等待 / 唤醒逻辑的线程安全
等待一般都伴随共享变量条件判断（比如队列空 / 满、状态标志）：
- 共享变量本身就存在并发竞争，必须加锁保证可见性、原子性；
- 同步块天然保证：变量状态在线程间及时可见，避免因指令重排、内存可见性导致逻辑错乱。
三、补充最佳实践（面试常考）
wait()一定要放在while循环里防止虚假唤醒（线程可能在无 notify 时被意外唤醒）：synchronized (obj) { while (条件不满足) { obj.wait(); } // 执行业务 }notify()/notifyAll()也必须在同一个对象锁的同步块中。- 优先用
notifyAll()，多数场景下更安全。
面试极简背诵版
- 防止丢失唤醒：锁让「条件判断 + wait」原子执行，避免唤醒先于等待发生；
- JVM 强制校验：调用这两个方法必须持有对象监视器，否则抛
IllegalMonitorStateException； - 保证线程安全：同步锁保障条件变量的可见性与原子性。