如何应对未获取对象锁时使用waitnotify引发的IllegalMonitorStateException异常？

本文共计785个文字，预计阅读时间需要4分钟。

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）通常能提前标出这类错误
• 单元测试中加入多线程压力路径，让异常尽早暴露