BlockingQueue methods come in four forms, with different ways of 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 null or 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:
| 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 BlockingQueue does not accept null elements. Implementations throw NullPointerException on attempts to add, put or offer a null. A null is used as a sentinel value to indicate failure of poll operations.
A BlockingQueue may be capacity bounded. At any given time it may have a remainingCapacity beyond which no additional elements can be put without blocking. A BlockingQueue without any intrinsic capacity constraints always reports a remaining capacity of Integer.MAX_VALUE.
BlockingQueue implementations are designed to be used primarily 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 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.
BlockingQueue implementations are thread-safe. All queuing methods achieve their effects atomically using internal locks or other forms of concurrency control. However, the bulk Collection operations addAll, containsAll, retainAll and removeAll are not necessarily performed atomically unless specified otherwise in an implementation. So it is possible, for example, for addAll(c) to fail (throwing an exception) after adding only some of the elements in c.
A BlockingQueue does not intrinsically support any 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 BlockingQueue can safely be used with multiple producers and multiple consumers.
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(); } } This interface is a member of the Java Collections Framework. @since 1.5 @author Doug Lea
{@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:
| 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
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |