[ACCEPTED]-Where should you use BlockingQueue Implementations instead of Simple Queue Implementations?-queue

A limited capacity BlockingQueue is also helpful if you 60 want to throttle some sort of request. With 59 an unbounded queue, a producers can get 58 far ahead of the consumers. The tasks will 57 eventually be performed (unless there are 56 so many that they cause an OutOfMemoryError), but the producer 55 may long since have given up, so the effort 54 is wasted.

In situations like these, it 53 may be better to signal a would-be producer 52 that the queue is full, and to give up quickly 51 with a failure. For example, the producer 50 might be a web request, with a user that 49 doesn't want to wait too long, and even 48 though it won't consume many CPU cycles 47 while waiting, it is using up limited resources 46 like a socket and some memory. Giving up 45 will give the tasks that have been queued 44 already a better chance to finish in a timely 43 manner.

Regarding the amended question, which 42 I'm interpreting as, "What is a good 41 collection for holding objects in a pool?"

An 40 unbounded LinkedBlockingQueue is a good choice for many pools. However, depending 39 on your pool management strategy, a ConcurrentLinkedQueue may 38 work too.

In a pooling application, a blocking 37 "put" is not appropriate. Controlling 36 the maximum size of the queue is the job 35 of the pool manager—it decides 34 when to create or destroy resources for 33 the pool. Clients of the pool borrow and 32 return resources from the pool. Adding a 31 new object, or returning a previously borrowed 30 object to the pool should be fast, non-blocking 29 operations. So, a bounded capacity queue 28 is not a good choice for pools.

On the other 27 hand, when retrieving an object from the 26 pool, most applications want to wait until 25 a resource is available. A "take" operation 24 that blocks, at least temporarily, is much 23 more efficient than a "busy wait"—repeatedly 22 polling until a resource is available. The 21 LinkedBlockingQueue is a good choice in this case. A borrower 20 can block indefinitely with take, or limit the 19 time it is willing to block with poll.

A less 18 common case in when a client is not willing 17 to block at all, but has the ability to 16 create a resource for itself if the pool 15 is empty. In that case, a ConcurrentLinkedQueue is a good choice. This 14 is sort of a gray area where it would be 13 nice to share a resource (e.g., memory) as 12 much as possible, but speed is even more 11 important. In the worse case, this degenerates 10 to every thread having its own instance 9 of the resource; then it would have been 8 more efficient not to bother trying to share 7 among threads.

Both of these collections 6 give good performance and ease of use in 5 a concurrent application. For non-concurrent 4 applications, an ArrayList is hard to beat. Even 3 for collections that grow dynamically, the 2 per-element overhead of a LinkedList allows an ArrayList with 1 some empty slots to stay competitive memory-wise.

You would see BlockingQueue in multi-threaded situations. For 4 example you need pass in a BlockingQueue as a parameter 3 to create ThreadPoolExecutor if you want to create one using 2 constructor. Depending on the type of queue 1 you pass in the executor could act differently.

It is a Queue implementation that additionally 6 supports operations that

wait for the queue 5 to become non-empty when retrieving an element,

and 4

wait for space to become available in the 3 queue when storing an element.

If you required 2 above functionality will be followed by 1 your Queue implementation then use Blocking Queue