我希望以原子无锁的方式使用ConcurrentLinkedQueue：
多个并发线程将事件推入队列，而其他一些线程将处理它们。队列没有绑定，我不希望任何线程等待或被锁定。然而，读取部分可能会注意到队列已经为空。在无锁实现中，读取线程不能阻塞，而只能结束其任务并继续执行其他任务（即作为ExecutorService）。因此，将第一个新事件推入空队列的写入者必须意识到这一点，并应重新启动读取器（即通过向ExecutorService提交新的Runnable来完成）。后续提交第二个或第三个事件的任何其他线程都不需要关心，因为它们可以假设某个读取器已经准备好/提交。
很遗憾，ConcurrentLinkedQueue的 add() 方法总是返回 true。在添加事件之前或之后询问队列是否为空并不会有帮助，因为它不是原子性的。我应该使用一些额外的AtomicInteger来监视队列的 size()，还是有更聪明的解决方案？我不太明白为什么你不直接使用ExecutorService来完成这个任务。它在内部使用了一个BlockingQueue，并且自己处理了所有的信号。
// open ended thread pool
ExecutorService threadPool = Executors.newFixedThreadPool(1);
for (Job job : jobsToDo) {
threadPool.submit(new MyJobProcessor(job));
}
除非你有充分的理由，否则不要自己重写相同的逻辑。
如果你想要利用休眠线程，我强烈建议你不要费心。线程是相对便宜的，所以分配一个线程来处理你排队的任务是可以的。重复使用线程是不必要的，并且对我来说似乎是过早优化。
ExecutorService是瓶颈，否则让事情变得更复杂是没有意义的。 - Gray使用AtomicInteger来解决提交争用比锁或synchronized块更有效。
ConcurrentLinkedQueue，覆盖add()方法，如果需要，触发处理器线程。您可能会遇到两个或多个处理器线程被触发的竞争条件，但它们可以使用同步锁来处理 - 唯一会发生阻塞的是很快就会死亡的线程，没有合法的工作线程会被阻塞。 - corsiKa