java - 您应该在哪里使用 BlockingQueue 实现而不是简单队列实现？

Question

我想我应该从

重新提出我的问题

您应该在哪里使用 BlockingQueue 实现而不是简单队列实现？

到

BlockingQueue 相对于队列实现的优点/缺点是什么，考虑到速度、并发性或其他不同的属性，例如是时候访问最后一个元素了。

我用过这两种队列。我知道阻塞队列通常用于并发应用程序。我正在编写简单的 ByteBuffer 池，我需要一些 ByteBuffer 对象的占位符。我需要最快的、线程安全的队列实现。甚至还有像 ArrayList 这样的 List 实现，它对元素具有恒定的访问时间。

任何人都可以讨论 BlockingQueue 与 Queue 与 List 实现的优缺点吗？

目前我使用 ArrayList 来保存这些 ByteBuffer 对象。

我应该使用哪种数据结构来保存这些对象？

Answer 1

如果您想限制某种请求，有限容量的 BlockingQueue 也很有帮助。使用无界队列，生产者可以远远领先于消费者。这些任务最终会被执行(除非有太多导致OutOfMemoryError)，但生产者可能早就放弃了，所以努力就白费了。

在这种情况下，最好向潜在的生产者发出队列已满的信号，并在失败后迅速放弃。例如，生产者可能是一个 web 请求，用户不想等待太久，即使它在等待时不会消耗很多 CPU 周期，但它正在使用有限的资源，如套接字和一些内存.放弃会让已经排队的任务有更好的机会及时完成。

---

关于修改后的问题，我将其解释为“什么是在池中保存对象的好集合？”

无界LinkedBlockingQueue是很多泳池的不错选择。但是，根据您的池管理策略，ConcurrentLinkedQueue也可以。

在池应用程序中，阻塞“放置”是不合适的。控制队列的最大大小是池管理器的工作——它决定何时为池创建或销毁资源。池的客户端从池中借用和归还资源。添加新对象，或将以前借用的对象返回到池中应该是快速、非阻塞的操作。因此，有限容量队列对于池来说不是一个好的选择。

另一方面，当从池中检索对象时，大多数应用程序都希望等到资源可用。至少暂时阻塞的“获取”操作比“忙等待”(重复轮询直到资源可用)效率高得多。 LinkedBlockingQueue 在这种情况下是一个不错的选择。借款人可以使用 take 无限期卡住，或使用 poll 限制它愿意阻止的时间.

一种不太常见的情况，即客户端根本不愿意阻塞，但如果池为空，则能够为自己创建资源。在这种情况下，ConcurrentLinkedQueue 是一个不错的选择。这是一个灰色区域，尽可能多地共享资源(例如内存)会很好，但速度更为重要。在更坏的情况下，这会退化为每个线程都有自己的资源实例；那么不用费心尝试在线程之间共享会更有效。

这两个集合都在并发应用程序中提供了良好的性能和易用性。对于非并发应用程序，ArrayList 很难被击败。即使对于动态增长的集合，LinkedList 的每个元素开销也允许具有一些空槽的 ArrayList 在内存方面保持竞争力。