| * | Throws exception | *Returns 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 is * possible 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
* @param Note that you cannot always tell if
* an attempt to add an element will succeed by
* inspecting remainingCapacity because it may be the
* case that another thread is about to put or take an
* element.
* @return the remaining capacity
*/
int remainingCapacity();
/**
* Adds the specified element to this queue if it is possible to
* do so immediately, returning true upon success, else
* throwing an IllegalStateException.
* @param o the element
* @return true (as per the general contract of
* Collection.add).
*
* @throws NullPointerException if the specified element is null
* @throws IllegalStateException if element cannot be added
*/
boolean add(E o);
/**
* Removes all available elements from this queue and adds them
* into the given collection. This operation may be more
* efficient than repeatedly polling this queue. A failure
* encountered while attempting to add elements to
* collection c may result in elements being in neither,
* either or both collections when the associated exception is
* thrown. Attempts to drain a queue to itself result in
* IllegalArgumentException. Further, the behavior of
* this operation is undefined if the specified collection is
* modified while the operation is in progress.
*
* @param c the collection to transfer elements into
* @return the number of elements transferred.
* @throws NullPointerException if c is null
* @throws IllegalArgumentException if c is this queue
*
*/
int drainTo(Collection c);
/**
* Removes at most the given number of available elements from
* this queue and adds them into the given collection. A failure
* encountered while attempting to add elements to
* collection c may result in elements being in neither,
* either or both collections when the associated exception is
* thrown. Attempts to drain a queue to itself result in
* IllegalArgumentException. Further, the behavior of
* this operation is undefined if the specified collection is
* modified while the operation is in progress.
*
* @param c the collection to transfer elements into
* @param maxElements the maximum number of elements to transfer
* @return the number of elements transferred.
* @throws NullPointerException if c is null
* @throws IllegalArgumentException if c is this queue
*/
int drainTo(Collection c, int maxElements);
}