java - ReentrantLock and Condition，最佳设计

Question

我正在资源池的上下文中使用 ReentrantLock 中的条件，据我所知，它简化了线程通信。我的问题是，我最终有机地编写了奇怪的条件，例如 acquireMapEmpty、freeQueueNotEmpty、更改等待和单个不同的东西。从技术上讲，它们可以全部替换为一个条件或分解为多个条件 - 是否有以下经验法则:

1. 确定条件
2. 弄清楚您的数量是否过多或过少
3. 当您走在正确的轨道上或偏离轨道时

以下是删除资源的示例。

 public boolean remove(R resource) throws InterruptedException {

    System.out.println("Remove, resource: " + resource + " with thread: " + Thread.currentThread().getName());
    if (resource == null) {
        throw new NullPointerException();
    }
    mainLock.lock();
    try {
        if (!isOpen) {
            throw new IllegalStateException("Not open");
        }
        Object lock = locks.get(resource);
        if (lock == null) {
            return false;
        }
        if (freeQueue.remove(resource)) {
            locks.remove(resource);
            if (!freeQueue.isEmpty()) {
                freeQueueNotEmpty.signalAll();
            }
            return true;
        }
        while (!freeQueue.contains(resource)) {
            change.await();
            if (!isOpen) {
                throw new IllegalStateException("Not open");
            }
            lock = locks.get(resource);
            if (lock == null) {
                return false;
            }
        }
        if (freeQueue.remove(resource)) {
            locks.remove(resource);
            if (!freeQueue.isEmpty()) {
                freeQueueNotEmpty.signalAll();
            }
            return true;
        }
        return false;
    } finally {
        mainLock.unlock();
    }
}

Answer 1

嗯，根据经验，我倾向于拥有与线程阻塞的原因一样多的条件变量。基本原理是，当您发出条件变量信号时，您想要唤醒一个正在等待您发出信号的状态的特定变化的线程，并且您真的非常想避免“惊群”综合症 - 唤醒 所有线程，在某个条件下被阻塞，只是让其中一个取得进展，而所有其他线程又回到 sleep 状态，同时浪费了宝贵的CPU时间并破坏了缓存。