wait()必须在synchronized块中调用，否则抛illegalmonitorstateexception；notify()随机唤醒一个线程，notifyall()唤醒所有等待线程；wait()需置于while循环中以防虚假唤醒。
为什么 wait() 必须在 synchronized 块里调用
因为 wait() 会释放当前线程持有的锁，而 JVM 要求这个锁必须是它正在等待的那个对象的监视器锁。没加锁就调用，直接抛 IllegalMonitorStateException。
常见错误现象：代码看起来“逻辑对”，但一运行就崩在 wait() 那行，堆栈里清清楚楚写着 IllegalMonitorStateException。
- 必须用
synchronized(obj) { obj.wait(); }，不能写成obj.wait()单独一行 - 如果锁的是
this，那wait()前后都得在synchronized(this)块内 - 别用字符串字面量或常量池对象当锁（比如
synchronized("lock")），不同类加载器或模块可能拿到不同实例，导致锁失效
notify() 和 notifyAll() 的实际唤醒行为差异
notify() 只随机唤醒一个在该对象上 wait() 的线程；notifyAll() 唤醒所有。但注意：唤醒 ≠ 立即执行 —— 被唤醒线程还得重新竞争锁，拿到锁后才从 wait() 返回。
生产者消费者模型里，如果只用 notify()，容易卡死：比如缓冲区满时生产者 wait()，消费者消费完后只 notify() 一个生产者，但此时另一个消费者也刚消费完、顺手又 notify() 了同一线程，剩下那个生产者永远没人叫。
立即学习“Java免费学习笔记（深入）”；
- 缓冲区有多个生产者/消费者时，优先用
notifyAll()，避免信号丢失 -
notify()仅适合严格一对一协作（如单生产者单消费者 + 明确状态机），且需确保每次 notify 都对应一个确定等待者 - 不要假设唤醒顺序 —— JVM 不保证 FIFO，也不按等待时间排序
为什么 wait() 要放在 while 循环里，而不是 if
虚假唤醒（spurious wakeup）是真实存在的：线程可能没被 notify() 就自己醒了。JVM 规范允许这么做，Linux 的 futex 和 HotSpot 实现都可能触发。
典型症状：消费者发现缓冲区空，进入 wait()；醒来后直接取数据，结果 IndexOutOfBoundsException 或 NullPointerException。
- 永远用
while (conditionNotMet) { obj.wait(); }，别用if - 检查条件必须和
wait()所依赖的状态完全一致，比如while (queue.isEmpty())，不能简化为while (queue.size() == 0)（虽然等价，但可读性差、易错） - 条件变量要
volatile或受同一把锁保护，否则可能读到过期值
生产者消费者中缓冲区容量变化时的边界处理
缓冲区大小不是固定值时（比如动态扩容队列），wait()/notify() 的触发点容易错位。例如扩容后消费者还在等“非空”，但生产者刚写完就 notify()，而此时缓冲区其实已满，下一个生产者立刻阻塞 —— 表面看没问题，实则吞吐骤降。
根本问题在于：状态判断和通知没有原子绑定。一个操作改了多个状态（如 size + capacity），但只基于其中一个发通知。
- 用
LinkedBlockingQueue这类 JDK 原生线程安全队列，内部已处理好所有边界 - 手写时，所有影响等待条件的修改（add/remove/capacity change）必须在同一个
synchronized块里完成，并在末尾统一notifyAll() - 避免在
wait()前做耗时操作（如 IO、复杂计算），否则会拉长锁持有时间，拖慢其他线程
真正难的不是写对 wait 和 notify，而是想清楚“谁在等什么、谁该什么时候喊一声、喊完别人会不会听错”。状态耦合越紧，越容易漏掉某个 notify 场景。
