Java ReentrantLock 条件队列怎么避免虚假唤醒：await、signal 与队列状态核验

把线程从 wait/notify 迁到 ReentrantLock 时，最容易留下的不是锁没释放，而是条件判断只执行了一次：线程被唤醒后直接往下走，队列却已经被别的线程取空。正确做法是让每个 Condition.await() 都处在 while 谓词检查里，并在持锁状态下用 signal() 或 signalAll() 改变等待者能观察到的条件。

从 wait/notify 到 Condition，真正变化在哪里

用ReentrantLock的Condition实现等待逻辑时，必须在循环中调用await()校验条件状态，不能用if单次判断，依靠signal唤醒后线程会重新进入同步队列抢锁，抢到锁后还会再次校验前置条件，从机制层面规避多线程场景下的虚假唤醒问题。

synchronized 的对象监视器只有一组等待队列。换成 ReentrantLock 后，可以为“有数据可取”和“有空位可放”分别创建 Condition，例如 notEmpty 与 notFull。这不是把方法名机械替换，而是把一个模糊的通知入口拆成了两个业务条件。

关键规则只有一句：等待前检查条件，醒来后再次检查条件。await() 期间线程会释放锁，其他线程才有机会修改 count；它返回时重新拿到锁，并不代表“轮到我消费”的事实仍然成立。

用有界缓冲区写出可核验的最小实现

下面这个缓冲区只保留与条件队列有关的状态。put 在放入元素后通知取数据的一侧，take 在取走元素后通知放数据的一侧；两个状态变更都发生在同一把锁保护的临界区内。

final class BoundedBuffer {
    private final ReentrantLock lock = new ReentrantLock();
    private final Condition notEmpty = lock.newCondition();
    private final Condition notFull = lock.newCondition();
    private final Object[] items = new Object[8];
    private int putIndex, takeIndex, count;

    void put(T value) throws InterruptedException {
        lock.lockInterruptibly();
        try {
            while (count == items.length) {
                notFull.await();
            }
            items[putIndex] = value;
            putIndex = (putIndex + 1) % items.length;
            count++;
            notEmpty.signal();
        } finally {
            lock.unlock();
        }
    }

    @SuppressWarnings("unchecked")
    T take() throws InterruptedException {
        lock.lockInterruptibly();
        try {
            while (count == 0) {
                notEmpty.await();
            }
            T value = (T) items[takeIndex];
            items[takeIndex] = null;
            takeIndex = (takeIndex + 1) % items.length;
            count--;
            notFull.signal();
            return value;
        } finally {
            lock.unlock();
        }
    }
}

这里的 while 不是写法偏好。两个消费者同时等待时，生产者放入一个元素并发出通知，只有一个消费者最终能取走它；另一个消费者即使已经从等待队列返回，也必须重新看到 count == 0，然后继续等待。

signal 和 signalAll 的选择要跟状态变化绑定

signal() 只转移一个等待线程，适合一次只新增一个可消费元素、或一次只释放一个空位的队列。它不能替代条件检查，也不能在没有持有这把锁时调用。

signalAll() 会让同一条件上的等待者陆续竞争锁。它适合批量改变状态、关闭队列或需要让所有等待者重新观察终止标记的场景，但代价是更多线程被唤醒后又回到等待。无论选择哪一个，通知动作都应该放在状态更新之后。

迁移旧代码时，四个边界必须重新确认

不要把 if (count == 0) 当成 await 的前置模板

把 if 改成 while 是第一处修复。虚假唤醒、多个消费者竞争、广播通知都会让“刚刚为空”不再等于“现在仍为空”。

锁、条件和共享状态必须属于同一个对象

如果生产者用一把锁修改 count，消费者却在另一把锁的条件队列上等待，通知与状态之间就没有可见性和互斥关系。迁移时把字段、锁和两个条件放在同一个缓冲区对象里，最容易审查。

中断要成为可观察的退出路径

lockInterruptibly() 和 await() 都可能抛出 InterruptedException。调用方要决定是向上抛出、恢复中断标记，还是把任务标记为取消；不要捕获后静默继续消费。

关闭流程不能只 signal 一个消费者

如果队列增加了 closed 状态，关闭时通常要在锁内修改状态，再调用 signalAll()，让所有等待者检查“已关闭且无剩余数据”的退出条件。

最小验证：让等待、竞争和中断都能被复现

单元测试至少准备一个容量为 1 的缓冲区。先启动两个消费者让它们等待，再只放入一个元素，断言只有一个消费者拿到数据；随后中断另一个等待线程，确认任务结束并且中断原因没有被吞掉。最后连续放入、取出多轮，核对 count 不越过 0 和容量上限。

assertTimeout(Duration.ofSeconds(2), () -> {
    BoundedBuffer buffer = new BoundedBuffer();
    ExecutorService pool = Executors.newFixedThreadPool(2);
    Future waiting = pool.submit(buffer::take);
    Thread.sleep(50);
    waiting.cancel(true);
    assertTrue(waiting.isCancelled());
    pool.shutdownNow();
});

这段测试只验证中断路径，竞争测试还要使用两个独立的 Future 和明确的超时。不要用固定长时间睡眠来证明线程“已经等待”；更稳妥的是在测试辅助代码中记录进入等待前的事件，或使用屏障控制阶段。

常见问题

await 返回后为什么还要重新判断条件？

因为返回只表示线程重新获得锁，不承诺条件仍然满足。其他线程可能已经消费或填充了状态，虚假唤醒也可能让等待提前返回。

signal 一定会唤醒最合适的线程吗？

它只负责从该条件队列转移一个等待者，具体获得锁和最终通过谓词检查仍由线程调度与循环判断决定。

什么时候应该使用 signalAll？

关闭队列、批量改变状态或所有等待者都必须重新检查公共状态时更合适；使用后仍必须保留 while。

总结

把条件队列写对，核心不是记住几个 API，而是把“状态谓词、持锁修改、通知时机、退出路径”放在同一条可验证链路上。先用 while 守住条件，再根据一次释放一个名额还是广播状态变化选择通知方式，最后用竞争和中断测试证明迁移没有丢掉边界。