illegalmonitorstateexception 是 jvm 检测到线程未持锁就调用 wait/notify 时抛出的运行时异常，用于暴露并发逻辑错误，而非容错；必须通过预防（如确保在 synchronized 块内调用）而非捕获来处理。
IllegalMonitorStateException 不是用来“处理”异常的，而是 JVM 在检测到线程未持有对象锁就调用 wait()、notify() 或 notifyAll() 时，抛出的运行时异常。它的作用是**暴露并发逻辑错误**，而非提供容错或恢复机制。正确做法是预防，而非捕获或利用它。
为什么不能靠捕获 IllegalMonitorStateException 来“处理”问题
该异常表明代码违反了 Java 内存模型的基本同步契约——wait/notify 必须在 synchronized 块或方法内执行。捕获它相当于掩盖设计缺陷：
- 掩盖了缺少同步块的根本问题，可能导致竞态、丢失唤醒、虚假唤醒等更隐蔽的并发 bug
- 异常发生在运行时，无法静态检查；依赖异常流控制会降低可读性和可维护性
- JVM 不保证该异常一定会被抛出（极少数 JIT 优化场景下可能表现不同），不可作为逻辑分支依据
正确的预防方式：严格遵守 wait/notify 使用规范
确保每次调用前，当前线程已通过 synchronized 获得目标对象的内部锁：
-
wait()、notify()、notifyAll()只能出现在synchronized(obj) { ... }块中，且obj必须与调用者一致 - 不要在
ReentrantLock等显式锁上使用wait/notify——它们只适用于内置锁（monitor） - 避免在继承链中意外调用父类未同步的
wait/notify方法
示例（正确）：
synchronized (lock) {while (!conditionMet) {
lock.wait(); // ✅ 在 synchronized 块内
}
// 处理业务逻辑
}
现代替代方案：优先使用 java.util.concurrent 工具类
绝大多数场景下，应避免直接使用 wait/notify，改用更高层次、更安全的并发原语：
- 用
Condition配合ReentrantLock实现精准等待/唤醒（支持多个条件队列） - 用
BlockingQueue（如LinkedBlockingQueue）替代手动实现生产者-消费者等待逻辑 - 用
CountDownLatch、CyclicBarrier、Semaphore表达明确的同步意图 - 用
CompletableFuture或StructuredTaskScope（Java 21+）管理异步协作
调试与诊断：把 IllegalMonitorStateException 当作信号
当它出现时，应立即定位并修复同步结构，而不是兜底：
- 检查堆栈跟踪，确认哪一行调用了
wait/notify - 向上追溯，确认该行是否在
synchronized块内，以及锁对象是否匹配 - 注意 IDE 或静态分析工具（如 IntelliJ 的 inspections、SpotBugs）通常能提前标出这类错误
- 单元测试中加入多线程压力路径，让异常尽早暴露
