等待空阻塞队列的首选方法

Question

我有一个多线程应用程序，其中一个线程将项目放入< code>BlockingQueue中，多个线程从中取出项目进行处理。问题是关于从队列中获取项目，目前它是这样实现的:

class PriorityQueueWorker<T> implements Runnable {
  private final PriorityBlockingQueue<T> requestQueue;
  private final AtomicBoolean continueExecution;

  @Override
  public void run() {
    do {
      T request = null;
      try {
        request = requestQueue.take();
      } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        continueExecution.set(false);
      }

      if (request == null) {
        continue;
      }

      //... here we do the work

    } while (continueExecution.get());

}

根据＜code＞BlockingQueue的JavaDoc。take（）它检索并删除队列的头部，如果需要，等待元素可用，对于＜code＞PriorityBlockingQueue直到队列中出现一个项目：

public E take() throws InterruptedException {
  final ReentrantLock lock = this.lock;
  lock.lockInterruptibly();
  E result;
  try {
    while ((result = dequeue()) == null)
      notEmpty.await();
  } finally {
    lock.unlock();
  }
  return result;
}

实现我们的逻辑的另一种方法是使用优先级阻止Queue.poll（），它在空队列的情况下返回空值：

public E poll() {
  final ReentrantLock lock = this.lock;
  lock.lock();
  try {
      return dequeue();
  } finally {
      lock.unlock();
  }
}

据我所知，这些方法的不同之处在于，使用fet（）线程在等待的空队列中被阻塞，而使用轮询（）它们继续围绕PriorityQueueWorker.run（）中的无限循环旋转。

对我来说，队列长时间为空的用例非常普遍，所以我的问题是哪种方法从性能角度来看更好：保持线程阻塞（采取方法）或保持它们旋转（轮询方法）？

Answer 1

从性能角度来看，哪种方法更好...？

“性能”对您意味着什么？

轮询空队列的工作线程将尝试使用 100% 的 CPU 内核。这将限制该内核代表任何其他线程工作的可用性。它还消耗电力，并产生热量。但是，如果应用程序中的线程数与 CPU 内核数仔细匹配，则可能会使工作线程更快地响应新工作项：当工作项到达时，很有可能某些工作线程已经处于核心中并正在运行并能够立即处理它。

在很多(大多数？)应用程序，OTOH，在应用程序中会有其他线程和在机器上运行的其他进程都希望共享CPU核心。在这种情况下，使用< code>take()可以在您的员工无事可做时释放CPU内核来做其他事情。那也是一种“表演”此外，使用< code>take()意味着您的应用将消耗更少的电力(如果您的应用可以在电池供电的设备上运行，这是一件大事)，并且它将产生更少的热量(如果您的应用在数据中心或炎热的环境中运行，这可能是一个问题)。)而< code>take()的缺点是，当一个新的工作项到达时，操作系统需要一些时间来“唤醒”一个等待的工作线程，以便它可以开始处理它。

IMO:您应该从< code>take()开始，只有在您确定(即，如果您已经测量了性能)您有问题，并且您确定(再次测量)轮询可以修复问题时，才尝试轮询。此外，除非您能够保证执行轮询的线程数量少于可用内核的数量，否则不要尝试轮询。