BlockingQueue中的take（）和put（）实现

Question

我了解BlockingQueue的理论和概念，但是当我查看LinkedBlockingQueue的实现时 。 我不明白为什么我们使用while循环继续尝试并在take()方法的第8行中等待（与put()相同）。 我认为if检查就足够了，因为从put()调用的signalNotEmpty()仅在第27行发出一个信号，但不是全部发出信号，因此只有一个等待线程被唤醒，对吗？ 我想知道我想念什么吗？ 有人可以解释为什么我们使用while不是if

这是代码片段

 1 public E take() throws InterruptedException {
 2      E x;
 3      int c = -1;
 4      final AtomicInteger count = this.count;
 5      final ReentrantLock takeLock = this.takeLock;
 6      takeLock.lockInterruptibly();
 7      try {
 8          while (count.get() == 0) {
 9               notEmpty.await();
10          }
11          x = dequeue();
12          c = count.getAndDecrement();
13          if (c > 1)
14             notEmpty.signal();
15      } finally {
16          takeLock.unlock();
17      }
18      if (c == capacity)
19          signalNotFull();
20      return x;
21 }
22
23 private void signalNotEmpty() {
24     final ReentrantLock takeLock = this.takeLock;
25     takeLock.lock();
26     try {
27         notEmpty.signal();
28     } finally {
29         takeLock.unlock();
30     }
31 }

如果我们将第8行更改为

if(count.get() == 0) { 
     notEmpty.await();
}

Answer 1

这是因为虚假的唤醒 。 请阅读条件类的javadoc，另请参阅是否确实发生了虚假唤醒？

* <h3>Implementation Considerations</h3>
 *
 * <p>When waiting upon a {@code Condition}, a &quot;<em>spurious
 * wakeup</em>&quot; is permitted to occur, in
 * general, as a concession to the underlying platform semantics.
 * This has little practical impact on most application programs as a
 * {@code Condition} should always be waited upon in a loop, testing
 * the state predicate that is being waited for.  An implementation is
 * free to remove the possibility of spurious wakeups but it is
 * recommended that applications programmers always assume that they can
 * occur and so always wait in a loop.

Answer 2

其原因是“虚假唤醒”。 参见： http : //docs.oracle.com/javase/7/docs/api/java/lang/Object.html#wait（）

Answer 3

这是为了赶上竞争状况，如果有多个线程正在等待并且都醒了，那么其他一些线程可能已经进行了信号量计数，因此每个线程都需要再次检查。