12.7 Queues (Schlangen) und Deques 

In der Klassenbibliothek von Java gibt es die Schnittstelle java.util.Queue für Datenstrukturen, die nach dem FIFO-Prinzip (First In First Out) arbeiten. Die verwandte Datenstruktur ist der Stack, der nach dem Prinzip LIFO (Last In First Out) arbeitet. Eine Deque bietet Methoden für die FIFO-Verarbeitung an beiden Enden über eine Schnittstelle java.util.Deque, die direkt java.util.Queue erweitert.
12.7.1 Die Schnittstelle Queue 

Die Schnittstelle Queue erweitert Collection und ist somit auch vom Typ Iterable. Zu den Klassen, die Queue implementieren, gehört unter anderem LinkedList.
Listing 12.18 com/tutego/insel/util/queue/QueueDemo.java, main()
Queue<String> queue = new LinkedList<String>(); queue.offer( "Fischers" ); queue.offer( "Fritze" ); queue.offer( "fischt" ); queue.offer( "frische" ); queue.offer( "Fische" ); queue.poll(); queue.offer( "Nein, es war Paul!" ); while ( !queue.isEmpty() ) System.out.println( queue.poll() );
interface java.util.Queue<E>
extends Collection<E> |
- boolean empty()
- E element()
- boolean offer( E o )
- E peek()
- E poll()
- E remove()
Auf den ersten Blick sieht es so aus, als ob es für das Erfragen zwei Methoden gibt: element() und peek(). Doch der Unterschied besteht darin, dass element() eine NoSuchElementException auslöst, wenn die Queue kein Element mehr liefern kann, peek() jedoch null bei leerer Queue liefert. Da null als Element erlaubt ist, kann peek() das nicht detektieren; die Rückgabe könnte für das null-Element oder als Anzeige für eine leere Queue stehen. Daher ist peek() nur sinnvoll, wenn keine null-Elemente vorkommen. Gefüllt wird die Liste statt mit add() – was durch Collection zur Verfügung stehen würde – mit offer(). Der Unterschied: Im Fehlerfall löst add() eine Exception aus, während offer() durch die Rückgabe false anzeigt, dass das Element nicht hinzugefügt wurde. Die folgende Tabelle macht den Zusammenhang deutlich:
Mit Ausnahme | Ohne Ausnahme | |
Einfügen |
add() |
offer() |
Erfragen |
element() |
peek() |
Löschen |
remove() |
poll() |
12.7.2 Blockierende Queues und Prioritätswarteschlangen 

Die Schnittstelle java.util.concurrent.BlockingQueue erweitert die Schnittstelle java. util.Queue. Klassen, die BlockingQueue implementieren, blockieren, falls eine Operation wie take() auf Grund fehlender Daten nicht durchgeführt werden konnte. Die Konsumenten/Produzenten sind mit diesen Klassen ausgesprochen einfach zu implementieren.
Spannende Queue-Klassen sind:
- ConcurrentLinkedQueue. Thread-sichere Queue durch verkettete Listen implementiert.
- DelayQueue. Queue, aus der die Elemente erst nach einer gewissen Zeit entnommen werden können.
- ArrayBlockingQueue. Queue mit einer maximalen Kapazität, abgebildet auf ein Feld.
- LinkedBlockingQueue. Queue beschränkt oder mit maximaler Kapazität, abgebildet durch eine verkettete Liste.
- PriorityQueue. Hält in einem Heap-Speicher Elemente sortiert und liefert bei Anfragen das jeweils kleinste Element. Wie beim TreeSet müssen die Elemente entweder Comparable implementieren, oder es muss ein Comparator angegeben werden. Unbeschränkt.
- PriorityBlockingQueue. Wie PriorityQueue, nur blockierend.
- SynchronousQueue. Eine blockierende Queue zum Austausch von genau einem Element. Wenn ein Thread ein Element in die Queue setzt, muss ein anderer Thread auf dieses Element warten, andernfalls blockiert die Datenstruktur den Ableger. Erwartet ein Thread ein Element, ohne dass ein anderer Thread etwas in die Queue gesetzt hat, blockiert sie ebenfalls den Holer. Durch diese Funktionsweise benötigt die SynchronousQueue keine Kapazität, denn Elemente werden, falls platziert, direkt konsumiert und müssen nicht zwischengelagert werden.
Die Priority-Klassen implementieren im Gegensatz zu den übrigen kein FIFO-Verhalten.
12.7.3 Deque-Klassen 

Die LinkedList ist eine Klasse, die schon Queue implementierte und seit dem Auftreten der Datenstruktur Deque in Java 6 auch die Schnittstelle Deque realisiert. Zwei Implementierungen von Deque sind ArrayDeque und LinkedBlockingDeque. Wie der Name ArrayDeque schon andeutet, sitzt hinter dieser Realisierung ein Feld, was die Deque beschränkten kann – einer LinkedList ist diese Beschränkung fremd. Die LinkedBlockingDeque realisiert BlockingDeque als blockierende Deque, was weder ArrayDeque noch LinkedList machen.