Queue
is a collection for holding elements prior to processing. Besides
basic Collection
operations, queues provide additional insertion,
removal, and inspection operations. The Queue
interface follows.
public interface Queue<E> extends Collection<E> { E element(); boolean offer(E e); E peek(); E poll(); E remove(); }
Queue
method exists in two forms: (1) one throws an exception if the operation fails, and (2) the other returns a special value if the operation fails (either null
or false
, depending on the operation). The regular structure of the
interface is illustrated in
the following table.
Type of Operation | Throws exception | Returns special value |
---|---|---|
Insert | add(e) |
offer(e) |
Remove | remove() |
poll() |
Examine | element() |
peek() |
remove
or poll
. In a FIFO queue, all new elements are inserted at the tail of the queue. Other kinds of queues may use different placement rules. Every Queue
implementation must specify its ordering properties.
It is possible for a Queue
implementation to restrict the number of elements that it holds; such queues are known as bounded. Some Queue
implementations in java.util.concurrent
are bounded, but the implementations in java.util
are not.
The add
method, which Queue
inherits from
Collection
, inserts an element unless it would violate the
queue's capacity restrictions, in which case it throws
IllegalStateException
. The offer
method,
which is intended solely for use on bounded queues,
differs from add
only in that it indicates failure to insert an element by returning false
.
The remove
and poll
methods both remove and return
the head of the queue. Exactly which element gets removed is a function of
the queue's ordering policy. The remove
and poll
methods differ in their behavior only when the queue is empty. Under these
circumstances, remove
throws NoSuchElementException
,
while poll
returns null
.
The element
and peek
methods return, but do not remove, the head of the queue. They differ from one another in precisely the same fashion as remove
and poll
: If the queue is empty, element
throws NoSuchElementException
, while
peek
returns null
.
Queue
implementations generally do not allow insertion of null
elements. The LinkedList
implementation, which was retrofitted to implement Queue
, is an exception. For historical reasons, it permits null
elements, but you should refrain from taking advantage of this, because null
is used as a special return value by the poll
and peek
methods.
Queue implementations generally do not define element-based versions of the
equals
and hashCode
methods but instead inherit the
identity-based versions from Object
.
The Queue
interface does not define the blocking queue methods,
which are common in concurrent programming. These methods, which wait for
elements to appear or for space to become available, are defined in the interface
java.util.concurrent.BlockingQueue
, which extends Queue
.
In the following example program, a queue is used to implement a countdown timer. The queue is preloaded with all the integer values from a number specified on the command line to zero, in descending order. Then, the values are removed from the queue and printed at one-second intervals. The program is artificial in that it would be more natural to do the same thing without using a queue, but it illustrates the use of a queue to store elements prior to subsequent processing.
import java.util.*; public class Countdown { public static void main(String[] args) throws InterruptedException { int time = Integer.parseInt(args[0]); Queue<Integer> queue = new LinkedList<Integer>(); for (int i = time; i >= 0; i--) queue.add(i); while (!queue.isEmpty()) { System.out.println(queue.remove()); Thread.sleep(1000); } } }
sort
method provided in
Collections
, but it illustrates the behavior of priority queues.
static <E> List<E> heapSort(Collection<E> c) { Queue<E> queue = new PriorityQueue<E>(c); List<E> result = new ArrayList<E>(); while (!queue.isEmpty()) result.add(queue.remove()); return result; }