Java中wait()、notify()、notifyAll()必须在synchronized块中调用，wait()释放锁并进入等待队列，被唤醒后需重新竞争锁；notify()随机唤醒一个线程，notifyAll()唤醒所有线程；均需配合while循环条件检查以防虚假唤醒。
Java 中使用 Object 类的 wait()、notify() 和 notifyAll() 实现线程间通信，核心在于“在同步上下文中调用”和“配合条件变量使用”。这三个方法不是普通工具方法，而是 JVM 级别的线程协作原语，必须在 synchronized 块或方法中调用，否则会抛出 IllegalMonitorStateException。
wait() 必须在 synchronized 中调用并释放锁
wait() 会让当前线程进入等待状态，并自动释放它持有的对象监视器（即 synchronized 锁），直到被其他线程唤醒或超时。注意：它不会自动重新获取锁，而是进入该对象的等待队列；被唤醒后需重新竞争锁，获得锁后才继续执行。
- 调用前必须已持有该对象的锁（即在 synchronized(obj) 内）
- 建议始终用 while 循环检查条件，避免虚假唤醒（spurious wakeup）
- 不要用 if 判断条件后 wait —— 这是常见 bug 来源
notify() 和 notifyAll() 用于唤醒等待线程
notify() 随机唤醒一个在该对象上等待的线程；notifyAll() 唤醒所有等待线程。二者都不释放当前锁，唤醒只是让线程有机会重新竞争锁。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 唤醒操作本身不保证条件已满足，所以被唤醒的线程仍需再次检查条件
- 优先考虑
notifyAll()，除非能严格确保每次只有一个线程可推进（如生产者-消费者中单个槽位） - 不要在循环中反复 notify —— 可能导致信号丢失或重复唤醒
典型场景：生产者-消费者模型
以共享缓冲区为例，两个线程通过同一把锁（比如缓冲区对象本身）协调：
立即学习“Java免费学习笔记（深入）”；
- 生产者在缓冲区满时调用
buffer.wait()，空时写入并buffer.notifyAll() - 消费者在缓冲区空时调用
buffer.wait()，满时读取并buffer.notifyAll() - 所有对缓冲区 size/内容的访问都包裹在
synchronized(buffer)中
关键细节与避坑点
这些方法易错，主要陷阱集中在锁、条件和唤醒时机：
- 不能在静态方法里直接用
this.wait()—— 静态上下文没有 this，应同步在类对象上（synchronized(YourClass.class)） -
wait(long timeout)是带超时的版本，避免无限等待，但超时后仍要检查条件是否成立 - 永远不要假设唤醒就等于条件满足 —— 必须用 while + 条件变量双重校验
- 避免在不同对象上调用 wait/notify —— 必须是同一个对象实例，否则无法通信
