问题描述
我想我会重新构建我的问题
I think I shall reframe my question from
你应该在哪里使用BlockingQueue实现而不是简单队列实现？
Where should you use BlockingQueue Implementations instead of Simple Queue Implementations ?
到
BlockingQueue优于队列实现的优点/缺点是考虑速度，并发性或其他属性等因素而有所不同，例如是时候访问最后一个元素。
我使用过两种类型的队列。我知道Blocking Queue通常用于并发应用程序。我正在编写简单的ByteBuffer池，我需要一些ByteBuffer对象的占位符。我需要最快，线程安全的队列实现。甚至还有类似ArrayList的List实现，它对元素有持续的访问时间。
I have used both kind of Queues. I know that Blocking Queue is normally used in concurrent application. I was writing simple ByteBuffer pool where I needed some placeholder for ByteBuffer objects. I needed fastest , thread safe queue implementation. Even there are List implementations like ArrayList which has constant access time for elements.
任何人都可以讨论BlockingQueue与Queue vs List实现的优缺点吗？
Can anyone discuss about pros and cons of BlockingQueue vs Queue vs List implementations?
目前我使用ArrayList来保存这些ByteBuffer对象。
Currently I have used ArrayList to hold these ByteBuffer objects.
我应该使用哪种数据结构来保存这些对象？
推荐答案
限制容量 BlockingQueue 也有帮助你想扼杀某种要求。通过无限制的队列，生产者可以远远领先于消费者。最终将执行任务（除非它们导致 OutOfMemoryError ），但生产者可能早已放弃，因此浪费了精力。
A limited capacity BlockingQueue is also helpful if you want to throttle some sort of request. With an unbounded queue, a producers can get far ahead of the consumers. The tasks will eventually be performed (unless there are so many that they cause an OutOfMemoryError), but the producer may long since have given up, so the effort is wasted.
在这样的情况下，最好向潜在的生产者发出队列已满的信号，并在发生故障时快速放弃。例如，生产者可能是一个Web请求，用户不想等待太长时间，即使它在等待时不会消耗很多CPU周期，它也会耗尽有限的资源，如套接字和一些内存。放弃将使排队的任务更有机会及时完成。
In situations like these, it may be better to signal a would-be producer that the queue is full, and to give up quickly with a failure. For example, the producer might be a web request, with a user that doesn't want to wait too long, and even though it won't consume many CPU cycles while waiting, it is using up limited resources like a socket and some memory. Giving up will give the tasks that have been queued already a better chance to finish in a timely manner.
关于修改问题，我正在解释为什么是在池中保存对象的好集合？
Regarding the amended question, which I'm interpreting as, "What is a good collection for holding objects in a pool?"
无界是许多游泳池的好选择。但是，根据您的池管理策略，也可以使用。
An unbounded LinkedBlockingQueue is a good choice for many pools. However, depending on your pool management strategy, a ConcurrentLinkedQueue may work too.
在池化应用程序中，阻止put不是适当。控制队列的最大大小是池管理器的工作—它决定何时创建或销毁池的资源。池的客户端从池中借用和返回资源。添加新对象或将先前借用的对象返回到池应该是快速，无阻塞的操作。因此，有界容量队列不是池的好选择。
In a pooling application, a blocking "put" is not appropriate. Controlling the maximum size of the queue is the job of the pool manager—it decides when to create or destroy resources for the pool. Clients of the pool borrow and return resources from the pool. Adding a new object, or returning a previously borrowed object to the pool should be fast, non-blocking operations. So, a bounded capacity queue is not a good choice for pools.
另一方面，从池中检索对象时，大多数应用程序都希望等到资源是可用的。至少暂时阻止的接受操作比忙等待更有效 - 并且重复轮询直到资源可用。在这种情况下， LinkedBlockingQueue 是一个不错的选择。借款人可以无限期地阻止，或使用。
On the other hand, when retrieving an object from the pool, most applications want to wait until a resource is available. A "take" operation that blocks, at least temporarily, is much more efficient than a "busy wait"—repeatedly polling until a resource is available. The LinkedBlockingQueue is a good choice in this case. A borrower can block indefinitely with take, or limit the time it is willing to block with poll.
一个不太常见的情况，当客户端根本不愿意阻止，但是如果池为空则能够为自己创建资源。在这种情况下， ConcurrentLinkedQueue 是一个不错的选择。这是一个灰色区域，尽可能地共享资源（例如，存储器）会很好，但速度更重要。在更糟糕的情况下，这会退化为具有自己的资源实例的每个线程;那么在不尝试在线程之间共享会更有效率。
A less common case in when a client is not willing to block at all, but has the ability to create a resource for itself if the pool is empty. In that case, a ConcurrentLinkedQueue is a good choice. This is sort of a gray area where it would be nice to share a resource (e.g., memory) as much as possible, but speed is even more important. In the worse case, this degenerates to every thread having its own instance of the resource; then it would have been more efficient not to bother trying to share among threads.
这两个集合在并发应用程序中提供了良好的性能和易用性。对于非并发应用程序， ArrayList 很难被击败。即使对于动态增长的集合， LinkedList 的每元素开销也允许 ArrayList ，并留有一些空插槽具有竞争力的记忆。
Both of these collections give good performance and ease of use in a concurrent application. For non-concurrent applications, an ArrayList is hard to beat. Even for collections that grow dynamically, the per-element overhead of a LinkedList allows an ArrayList with some empty slots to stay competitive memory-wise.
这篇关于您应该在哪里使用BlockingQueue实现而不是简单队列实现？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！