领导者在DelayQueue中使用的究竟是什么？(What exactly is the leader used for in DelayQueue?)

 我想了解java.util.concurrent DelayQueue ，但leader让我困惑。 
 
 首先，我们可以实现一个没有这样的leader的DelayQueue： 
 
public boolean offer(E e) {
    final ReentrantLock lock = this.lock;
    lock.lock();
    try {
        q.offer(e);

        if (q.peek() == e) {
            available.signal();
        }
        return true;
    } finally {
        lock.unlock();
    }
}

public E take() throws InterruptedException {
    final ReentrantLock lock = this.lock;
    lock.lockInterruptibly();
    try {
        for (;;) {
            E first = q.peek();
            if (first == null) {
                available.await();
            } else {
                long delay = first.getDelay(TimeUnit.NANOSECONDS);
                if (delay <= 0) {
                    return q.poll();
                } else {
                    available.awaitNanos(delay);
                }
            }
        }
    } finally {
        lock.unlock();
    }
}
 
 其次，似乎并没有最小化不必要的定时等待 。 根据注释： 
 
 
 
 Leader-Follower模式的这种变体（ http://www.cs.wustl.edu/~schmidt/POSA/POSA2/ ）用于最小化不必要的定时等待 
 
 
 我认为最大限度地减少awaitNanos （使用await而不是awaitNanos ），但我真的怀疑这一点。 如果新元素不是队列的头部，则不会发送线程信号。 （见下面的offer方法） 
 
if (q.peek() == e) {
    leader = null;  // set leader to null
    available.signal();
}
 
 所以只有当新元素是头时才会有所作为。 但是在这种情况下， leader将被设置为null ，并且被通知的线程不会以这种方式进行（ take方法）： 
 
else if (leader != null)
    available.await();
 
 线程将始终执行awaitNanos 。 
 
 那么，有人可以向我解释吗？ 我在某个地方得到了错误的想法吗？ 

I was trying to understand DelayQueue in java.util.concurrent, but leader confused me.
 
First of all, we can implement a DelayQueue without leader like this:
 
public boolean offer(E e) {
    final ReentrantLock lock = this.lock;
    lock.lock();
    try {
        q.offer(e);

        if (q.peek() == e) {
            available.signal();
        }
        return true;
    } finally {
        lock.unlock();
    }
}

public E take() throws InterruptedException {
    final ReentrantLock lock = this.lock;
    lock.lockInterruptibly();
    try {
        for (;;) {
            E first = q.peek();
            if (first == null) {
                available.await();
            } else {
                long delay = first.getDelay(TimeUnit.NANOSECONDS);
                if (delay <= 0) {
                    return q.poll();
                } else {
                    available.awaitNanos(delay);
                }
            }
        }
    } finally {
        lock.unlock();
    }
}
 
Secondly, it seems does not minimize unnecessary timed waiting. According to the annotation:
 
 
 
This variant of the Leader-Follower pattern (http://www.cs.wustl.edu/~schmidt/POSA/POSA2/) serves to minimize unnecessary timed waiting
 
 
I take that as minimizing awaitNanos (using await instead of awaitNanos) but I really doubt that. If the new element isn't the head of the queue, then no thread will be signalled. (see offer method as below)
 
if (q.peek() == e) {
    leader = null;  // set leader to null
    available.signal();
}
 
So it only makes a difference when new elements is the head. But in this case, the leader will be set to null, and the signalled thread won't go this way(take method): 
 
else if (leader != null)
    available.await();
 
The thread will always do awaitNanos. 
 
So, can anybody explain that to me? Did I got the wrong idea somewhere? 

原文：https://stackoverflow.com/questions/48493830