| A {@link java.util.Queue} that additionally supports operations
that 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.
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 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();
}
}
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. | 