Interface Queue en Java | W3Docs Learn Java

Queue<E> est une Collection<E> à laquelle s'ajoute la notion de tête. La tête est le prochain élément à être supprimé ; tous les autres attendent leur tour derrière elle. La sémantique par défaut — et celle qu'utilise presque chaque implémentation du JDK — est FIFO : premier entré, premier sorti. Les producteurs insèrent des éléments à la fin via offer ; les consommateurs les récupèrent en tête via poll. Ce chapitre porte sur le contrat : les six méthodes, les deux styles de gestion des erreurs, la règle sur les valeurs null, et quelle implémentation choisir selon la situation.

Deux façons de faire chaque chose — par conception

Chaque opération de file d'attente existe en deux variantes : l'une qui lève une exception en cas d'échec, et l'autre qui renvoie une valeur spéciale. La Javadoc présente cela sous forme d'une grille 3×2 :

Opération	Lève une exception en cas d'échec	Renvoie une valeur spéciale
Insertion	`boolean add(E e)` (lève `IllegalStateException` si pleine)	`boolean offer(E e)` (renvoie `false` si pleine)
Suppression	`E remove()` (lève `NoSuchElementException` si vide)	`E poll()` (renvoie `null` si vide)
Examen	`E element()` (lève `NoSuchElementException` si vide)	`E peek()` (renvoie `null` si vide)

La colonne « lève une exception » est celle héritée de Collection et List — elle est familière mais peu pratique quand le cas vide/plein est normal (un consommateur attendant la prochaine tâche, une file bornée rejetant un producteur en excès). La colonne « renvoie une valeur spéciale » a été ajoutée pour les files afin que vous puissiez écrire des boucles qui ne s'appuient pas sur des exceptions pour le contrôle de flux :

String item;
while ((item = queue.poll()) != null) {
  process(item);
}

Utilisez la forme retour de valeur par défaut. Recourez à remove/element uniquement lorsqu'une file vide à ce stade serait un véritable bug que vous voudriez signaler par une exception.

Null et `Queue` ne font pas bon ménage

Parce que poll() et peek() renvoient null pour signifier « vide », autoriser null comme élément réel est une source d'ambiguïté. Chaque Queue généraliste du JDK, à l'exception de LinkedList, rejette null — ArrayDeque, PriorityQueue, ArrayBlockingQueue, toutes les files concurrentes. LinkedList vous laisse ajouter un null, mais ce faisant vous avez rompu le contrat : il n'est plus possible de distinguer « la tête est null » de « la file est vide ».

La règle : ne stockez pas null dans une file. Préférez ArrayDeque à LinkedList et le langage l'imposera pour vous.

FIFO est la valeur par défaut — mais pas universelle

Queue n'impose pas FIFO. L'interface définit une tête et des opérations qui en extraient des éléments ; la façon dont la tête est déterminée dépend de l'implémentation. Les deux implémentations de java.util qui ne sont pas FIFO sont :

PriorityQueue — la tête est toujours l'élément le plus petit (selon l'ordre naturel ou un Comparator). Les insertions se font là où le tas le dicte, pas en queue.
Les variantes bloquantes de java.util.concurrent — PriorityBlockingQueue, DelayQueue, etc. — réordonnent par priorité, échéance, etc.

Tout le reste (ArrayDeque, LinkedList, ArrayBlockingQueue, LinkedBlockingQueue, ConcurrentLinkedQueue) est FIFO.

Choisir une implémentation

Pour le cas mono-thread :

ArrayDeque — le choix par défaut. Tableau circulaire, sans allocation par élément, rapide. Utilisez-le comme Queue<E> ou comme Deque<E> selon que vous avez besoin d'accéder aux deux extrémités.
LinkedList — fonctionne, implémente également List. Choisissez-le uniquement si vous avez vraiment besoin des deux interfaces sur le même objet. Le chapitre sur LinkedList couvre les compromis.
PriorityQueue — quand vous voulez « l'élément en attente le plus petit en premier » plutôt que FIFO.

Pour le cas multi-thread (couvert en détail dans la partie concurrence plus loin — indications seulement ici) :

ConcurrentLinkedQueue — FIFO sans verrou. Non borné.
ArrayBlockingQueue — borné, sauvegardé par un tableau, bloque put quand plein et take quand vide. La file producteur/consommateur classique.
LinkedBlockingQueue — optionnellement borné, version à nœuds liés du même principe.
PriorityBlockingQueue — PriorityQueue concurrent. Non borné.

La plupart du code applicatif utilise l'un des quatre premiers. Les files bloquantes sont la façon de construire des pools de workers et de la contre-pression.

Ce que vous pouvez appeler sur n'importe quelle `Queue`

Au-delà des six méthodes spécifiques à la tête, une Queue est aussi une Collection — donc size, isEmpty, contains, iterator, forEach, stream, clear, toArray fonctionnent toutes. L'ordre d'itération est l'ordre dans lequel les éléments seraient retirés par poll pour les implémentations FIFO (ArrayDeque, LinkedList), mais pour PriorityQueue l'ordre d'itération n'est pas l'ordre de priorité — il visite le tableau du tas sous-jacent tel quel. Si vous voulez les éléments dans l'ordre de priorité, vous devez vider la file avec poll jusqu'à ce qu'elle soit vide.

Exemple concret : producteur/consommateur en un seul thread

Le programme ci-dessous utilise un ArrayDeque comme file FIFO pour modéliser un petit système de gestion d'impressions : les travaux arrivent au fil du temps (nous le représentons en insérant par lots via offer), et le worker vide chaque lot avec poll. La paire de styles d'erreur est montrée en haut afin que vous puissiez voir exactement quand chaque forme se déclenche.

java— editable, runs on the server

import java.util.*;

public class JobQueue {
  public static void main(String[] args) {
    Queue<String> jobs = new ArrayDeque<>();

// --- The two error styles, side by side ---
    System.out.println("poll on empty:  " + jobs.poll());   // returns null
    System.out.println("peek on empty:  " + jobs.peek());   // returns null
    try {
      jobs.remove();
    } catch (NoSuchElementException e) {
      System.out.println("remove on empty: threw NoSuchElementException");
    }
    try {
      jobs.element();
    } catch (NoSuchElementException e) {
      System.out.println("element on empty: threw NoSuchElementException");
    }

// --- ArrayDeque rejects null ---
    try {
      jobs.offer(null);
    } catch (NullPointerException e) {
      System.out.println("offer(null) on ArrayDeque: threw NullPointerException");
    }

System.out.println();

// --- Two batches of jobs, drained in FIFO order ---
    String[] batch1 = { "report.pdf", "invoice.pdf", "poster.png" };
    String[] batch2 = { "summary.docx", "slides.pptx" };

for (String j : batch1) jobs.offer(j);
    System.out.println("after batch1:  " + jobs);
    System.out.println("head (peek):    " + jobs.peek());
    System.out.println("polled:         " + jobs.poll());
    System.out.println("after poll:    " + jobs);

for (String j : batch2) jobs.offer(j);
    System.out.println("after batch2:  " + jobs);

// --- Drain pattern: while ((j = poll()) != null) ---
    System.out.println("\ndraining:");
    String j;
    while ((j = jobs.poll()) != null) {
      System.out.println("  printed: " + j);
    }
    System.out.println("queue empty? " + jobs.isEmpty());

// --- Priority queue: head is the smallest, not the first in ---
    Queue<Integer> pq = new PriorityQueue<>();
    pq.offer(40); pq.offer(10); pq.offer(30); pq.offer(20);
    System.out.println("\nPriorityQueue insertion order:  40, 10, 30, 20");
    System.out.print("poll order:                     ");
    while (!pq.isEmpty()) System.out.print(pq.poll() + " ");
    System.out.println();
  }
}

Quelques observations à tirer de l'exécution :

poll et peek ont renvoyé silencieusement null lorsque la file était vide ; remove et element ont levé des exceptions. Les deux comportements font partie du contrat — choisissez celui qui correspond à votre cas : « vide » est-il une erreur ou simplement un état ?
offer(null) a levé une exception sur ArrayDeque. C'est l'implémentation qui fait respecter la règle dont dépend l'interface.
La PriorityQueue a renvoyé 10, 20, 30, 40 par poll — dans l'ordre trié, pas dans l'ordre d'insertion. Même interface Queue, règle de sélection de la tête totalement différente.

Ce qui vient ensuite

La première implémentation non-FIFO mérite son propre chapitre — PriorityQueue est une file sauvegardée par un tas où la tête est toujours l'élément le plus petit. C'est l'ingrédient de base de presque tous les ordonnanceurs « traiter la tâche la plus urgente en premier » du JDK.

Pratique

Dans une boucle vous écrivez `while ((job = queue.poll()) != null) { process(job); }`. Si vous utilisiez `queue.remove()` à la place, qu'est-ce qui changerait au niveau du contrat ?

`remove()` lève `NoSuchElementException` quand la file est vide, donc la boucle devrait être enveloppée dans un `try/catch` ou vérifier `isEmpty()` au préalableRien — `remove()` et `poll()` sont des synonymes ; le JDK conserve les deux noms pour la compatibilité ascendante`remove()` bloquerait jusqu'à l'arrivée d'un nouvel élément ; c'est son rôle dans les files non-bloquantes`remove()` retournerait silencieusement `null` comme `poll()` parce que la file est vide