A {@link java.util.Queue} that additionally supports operationsthat wait for the queue to become non-empty when retrieving an element, and wait for space to become available in the queue when storing an element.
{@code BlockingQueue} methods come in four forms, with different waysof handling operations that cannot be satisfied immediately, but may be satisfied at some point in the future: one throws an exception, the second returns a special value (either {@code null} or {@code false}, depending on the operation), the third blocks the current thread indefinitely until the operation can succeed, and the fourth blocks for only a given maximum time limit before giving up. These methods are summarized in the following table:
Summary of BlockingQueue methods | Throws exception | Special value | Blocks | Times out |
Insert | {@link #add add(e)} | {@link #offer offer(e)} | {@link #put put(e)} | {@link #offer(Object,long,TimeUnit) offer(e, time, unit)} |
Remove | {@link #remove remove()} | {@link #poll poll()} | {@link #take take()} | {@link #poll(long,TimeUnit) poll(time, unit)} |
Examine | {@link #element element()} | {@link #peek peek()} | not applicable | not applicable |
A {@code BlockingQueue} does not accept {@code null} elements.Implementations throw {@code NullPointerException} on attemptsto {@code add}, {@code put} or {@code offer} a {@code null}. A {@code null} is used as a sentinel value to indicate failure of{@code poll} operations.
A {@code BlockingQueue} may be capacity bounded. At any giventime it may have a {@code remainingCapacity} beyond which noadditional elements can be {@code put} without blocking.A {@code BlockingQueue} without any intrinsic capacity constraints alwaysreports a remaining capacity of {@code Integer.MAX_VALUE}.
{@code BlockingQueue} implementations are designed to be usedprimarily for producer-consumer queues, but additionally support the {@link java.util.Collection} interface. So, for example, it ispossible to remove an arbitrary element from a queue using {@code remove(x)}. However, such operations are in general not performed very efficiently, and are intended for only occasional use, such as when a queued message is cancelled.
{@code BlockingQueue} implementations are thread-safe. Allqueuing methods achieve their effects atomically using internal locks or other forms of concurrency control. However, the bulk Collection operations {@code addAll}, {@code containsAll}, {@code retainAll} and {@code removeAll} arenot necessarily performed atomically unless specified otherwise in an implementation. So it is possible, for example, for {@code addAll(c)} to fail (throwing an exception) after addingonly some of the elements in {@code c}.
A {@code BlockingQueue} does not intrinsically supportany kind of "close" or "shutdown" operation to indicate that no more items will be added. The needs and usage of such features tend to be implementation-dependent. For example, a common tactic is for producers to insert special end-of-stream or poison objects, that are interpreted accordingly when taken by consumers.
Usage example, based on a typical producer-consumer scenario. Note that a {@code BlockingQueue} can safely be used with multipleproducers and multiple consumers.
{@code}class Producer implements Runnable private final BlockingQueue queue; Producer(BlockingQueue q) { queue = q; } public void run() { try { while (true) { queue.put(produce()); } } catch (InterruptedException ex) { ... handle ...} } Object produce() { ... } } class Consumer implements Runnable { private final BlockingQueue queue; Consumer(BlockingQueue q) { queue = q; } public void run() { try { while (true) { consume(queue.take()); } } catch (InterruptedException ex) { ... handle ...} } void consume(Object x) { ... } } class Setup { void main() { BlockingQueue q = new SomeQueueImplementation(); Producer p = new Producer(q); Consumer c1 = new Consumer(q); Consumer c2 = new Consumer(q); new Thread(p).start(); new Thread(c1).start(); new Thread(c2).start(); } }}
Memory consistency effects: As with other concurrent collections, actions in a thread prior to placing an object into a {@code BlockingQueue}happen-before actions subsequent to the access or removal of that element from the {@code BlockingQueue} in another thread.
This interface is a member of the Java Collections Framework.
@since 1.5
@author Doug Lea
@param < E> the type of elements held in this collection