Java Condition.signalAll 为什么必须在持锁时调用

在 Java 中，Condition.signalAll() 不是“随时都能调用的广播按钮”。它属于创建自己的那把 Lock，调用线程通常必须先持有这把锁，否则就会遇到 IllegalMonitorStateException。更重要的是：共享状态的修改、条件通知和解锁应该处在同一个临界区里，否则被唤醒的线程可能读到不一致的状态。

这篇只围绕一个问题展开：为什么 signalAll 必须在持锁时调用，以及怎样把 await、状态更新和 finally 解锁写成可排查的最小结构。

先看无锁 signalAll 的异常边界

先建立一个可观察的基线：让 3 个线程在同一个条件队列上等待，再让一个没有获取关联锁的线程调用一次 signalAll()。排查时可以记录三个指标：异常调用次数、共享状态写入次数、等待线程恢复次数。无锁调用的预期基线是“异常调用 1 次、状态写入 0 次、恢复线程 0 个”，这能把“没有唤醒”与“状态没有满足”区分开。

final ReentrantLock lock = new ReentrantLock();
final Condition ready = lock.newCondition();

void wrongNotify() {
    // 这里没有持有关联的 lock，通常会触发 IllegalMonitorStateException
    ready.signalAll();
}

Condition 是通过 lock.newCondition() 创建的，因而它的等待队列与这把锁绑定。这里的“持锁”不是指持有 Condition 对象的 Java 监视器，而是当前线程确实持有创建它的那把 ReentrantLock。把 synchronized (ready) 加在外面也不能替代 lock.lock()。

把状态更新和唤醒放进同一临界区

正确修复不是只给 signalAll() 前面补一行加锁，而是先保护状态，再通知等待者，最后无条件释放锁。等待线程真正关心的是状态谓词，例如“任务已经准备好”，通知本身只是提醒它重新检查这个谓词。

final ReentrantLock lock = new ReentrantLock();
final Condition ready = lock.newCondition();
boolean prepared;

void markPrepared() {
    lock.lock();
    try {
        // 状态写入和通知使用同一把关联锁，避免读到未发布状态
        prepared = true;
        ready.signalAll();
    } finally {
        // 无论通知是否抛出异常，都要释放当前线程持有的锁
        lock.unlock();
    }
}

void awaitPrepared() throws InterruptedException {
    lock.lock();
    try {
        // 用 while 重新检查谓词，覆盖虚假唤醒和竞争唤醒
        while (!prepared) {
            ready.await();
        }
    } finally {
        // await 返回时线程已经重新获取关联锁，这里负责最终释放
        lock.unlock();
    }
}

这个顺序的核心不是“先通知还是后通知”的口诀，而是所有读写 prepared 的线程都经过同一把锁。await() 会原子地释放关联锁并进入等待；被通知后，它还要重新取得该锁，成功后才会从 await() 返回。

用最小排查指标确认修复

为了避免只凭异常消失判断修复完成，可以保留三项计数：notifyAttempts 统计进入通知方法的次数，stateWrites 统计状态从未准备到已准备的写入次数，resumed 统计等待方法通过谓词检查后的线程数。对一个只允许状态切换一次、含 3 个等待线程的最小实验，稳定结果应接近“通知尝试 1、状态写入 1、恢复线程 3”。若通知尝试增加但状态写入仍为 0，通常是把通知放到了状态更新之前；若状态写入为 1 但恢复线程为 0，应继续检查是否使用了错误的 Condition 或是否根本没有进入等待队列。

这些数字是排查用的可复现实验规模，不是某个线上系统的性能承诺。性能上，signalAll 会让所有等待者竞争重新获取锁；如果实际上只需要一个线程继续工作，应该重新评估是否用 signal，但这不改变两者都应遵守的持锁前提。

三个容易混淆的边界

• Condition 监视器不等于关联 Lock：Condition 是普通对象，拿到它自身的监视器不能证明拿到了创建它的 Lock。
• 通知不等于状态：signalAll 只唤醒等待者，真正决定是否继续的是 while 中重新检查的共享状态。
• await 不能写成 if：虚假唤醒、多个线程竞争以及状态被其他线程先消费时，都要求返回后重新检查谓词。

常见问题

为什么 signalAll 之后线程没有立刻运行？ 因为被唤醒的线程还要重新获取关联锁，持锁线程退出临界区后它才有机会继续。

只把 signalAll 放进 lock.lock/unlock 就够了吗？ 不够。状态写入、谓词检查和通知要围绕同一把关联锁组织，并用 finally 确保解锁。

记住一条足够实用的规则：Condition 只负责等待队列，Lock 才负责状态的互斥与可见性。让同一把锁保护状态、await、signalAll 和 finally unlock，IllegalMonitorStateException 的来源和后续排查路径就都清楚了。