Интерфейс Queue в Java

Queue<E> — это Collection<E> плюс понятие головы. Голова — это следующий элемент, который будет удалён; все остальные ждут своей очереди за ним. Семантика по умолчанию — и та, которую использует почти каждая реализация в JDK — FIFO: первым пришёл, первым ушёл. Производители добавляют элементы в хвост через offer; потребители извлекают их из головы через poll. В этой главе рассматривается контракт: шесть методов, два стиля обработки ошибок, правило обработки null и какую реализацию выбирать в той или иной ситуации.

Два способа сделать каждое действие — по замыслу

Каждая операция с очередью существует в двух вариантах: один бросает исключение при неудаче, другой возвращает специальное значение. Javadoc представляет это в виде сетки 3×2:

Операция	Бросает исключение	Возвращает специальное значение
Вставка	`boolean add(E e)` (бросает `IllegalStateException`, если очередь заполнена)	`boolean offer(E e)` (возвращает `false`, если очередь заполнена)
Удаление	`E remove()` (бросает `NoSuchElementException`, если очередь пуста)	`E poll()` (возвращает `null`, если очередь пуста)
Просмотр	`E element()` (бросает `NoSuchElementException`, если очередь пуста)	`E peek()` (возвращает `null`, если очередь пуста)

Столбец «бросает исключение» унаследован от Collection и List — он привычен, но неудобен, когда случай пустой/заполненной очереди является нормой (потребитель ожидает следующей задачи, ограниченная очередь отклоняет лишнего производителя). Столбец «возвращает специальное значение» был добавлен для очередей, чтобы можно было писать циклы, не опираясь на исключения для управления потоком:

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

Используйте форму с возвратом значения по умолчанию. Прибегайте к remove/element только тогда, когда пустая очередь в данный момент является настоящей ошибкой, которую вы хотите обнаружить через исключение.

Null и `Queue` несовместимы

Поскольку poll() и peek() возвращают null для обозначения «пусто», допускать null в качестве реального элемента — значит создавать почву для неоднозначности. Каждая очередь общего назначения в JDK, за исключением LinkedList, отвергает null — ArrayDeque, PriorityQueue, ArrayBlockingQueue, все конкурентные очереди. LinkedList позволяет добавить null, но в этом случае вы нарушаете контракт: больше нет способа отличить «голова равна null» от «очередь пуста».

Правило: не храните null в очереди. Выбирайте ArrayDeque вместо LinkedList, и язык будет обеспечивать это за вас.

FIFO — поведение по умолчанию, но не универсальное

Queue не требует FIFO. Интерфейс определяет голову и операции, извлекающие из неё; то, как определяется голова, зависит от реализации. Две реализации в java.util, которые не являются FIFO:

PriorityQueue — головой всегда является наименьший элемент (по естественному порядку или через Comparator). Вставки происходят туда, куда предписывает куча, а не в хвост.
Блокирующие варианты в java.util.concurrent — PriorityBlockingQueue, DelayQueue и т. д. — упорядочивают по приоритету, дедлайну и пр.

Всё остальное (ArrayDeque, LinkedList, ArrayBlockingQueue, LinkedBlockingQueue, ConcurrentLinkedQueue) работает в режиме FIFO.

Выбор реализации

Для однопоточного случая:

ArrayDeque — по умолчанию. Кольцевой массив, без выделения памяти на каждый элемент, быстрый. Используйте как Queue<E> или как Deque<E> в зависимости от того, нужен ли вам доступ с обоих концов.
LinkedList — работает, также реализует List. Выбирайте только тогда, когда действительно нужны оба интерфейса на одном объекте. Глава о LinkedList охватывает компромиссы.
PriorityQueue — когда нужно «следующим берём наименьший ожидающий элемент», а не FIFO.

Для многопоточного случая (подробно рассматривается в части о конкурентности позже — здесь только указатели):

ConcurrentLinkedQueue — неблокирующий FIFO. Неограниченный.
ArrayBlockingQueue — ограниченный, на основе массива, блокирует put при заполнении и take при пустой очереди. Классическая очередь производитель/потребитель.
LinkedBlockingQueue — опционально ограниченный, вариант на связанных узлах.
PriorityBlockingQueue — конкурентный PriorityQueue. Неограниченный.

Большинство прикладного кода использует одну из первых четырёх. Блокирующие очереди — это инструмент для построения пулов воркеров и back-pressure.

Что можно вызвать на любом `Queue`

Помимо шести методов, специфичных для головы, Queue также является Collection — поэтому size, isEmpty, contains, iterator, forEach, stream, clear, toArray — всё это работает. Порядок итерации — это порядок, в котором элементы извлекались бы через poll для FIFO-реализаций (ArrayDeque, LinkedList), но для PriorityQueue порядок итератора не является порядком по приоритету — он обходит внутренний массив кучи как есть. Если вам нужны элементы в порядке приоритета, придётся опустошить очередь с помощью poll.

Рабочий пример: производитель/потребитель в одном потоке

Программа ниже использует ArrayDeque как FIFO-очередь для моделирования небольшой системы печати: задания поступают со временем (это представлено добавлением пакетами через offer), а воркер опустошает каждый пакет через poll. Пара стилей обработки ошибок показана вверху, чтобы вы могли точно увидеть, когда каждая форма срабатывает.

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();
  }
}

Несколько вещей, которые стоит отметить по результатам выполнения:

poll и peek тихо вернули null, когда очередь была пуста; remove и element бросили исключения. Оба поведения являются частью контракта — выбирайте то, которое соответствует тому, является ли «пусто» ошибкой или просто состоянием.
offer(null) бросило исключение на ArrayDeque. Это реализация обеспечивает выполнение правила, на которое опирается интерфейс.
PriorityQueue извлёк элементы в порядке 10, 20, 30, 40 — отсортированном порядке, а не порядке вставки. Тот же интерфейс Queue, но совершенно другое правило выбора головы.

Что дальше

Первая не-FIFO реализация заслуживает отдельной главы — PriorityQueue — это очередь на основе кучи, где головой всегда является наименьший элемент. Это базовый ингредиент практически любого планировщика «обработай наиболее срочную задачу следующей» в JDK.

Практика

Внутри цикла вы пишете `while ((job = queue.poll()) != null) { process(job); }`. Если вместо этого использовать `queue.remove()`, что изменится на уровне контракта?

`remove()` бросает `NoSuchElementException`, когда очередь пуста, поэтому цикл пришлось бы оборачивать в `try/catch` или сначала проверять `isEmpty()`Ничего — `remove()` и `poll()` являются синонимами; JDK сохраняет оба имени для обратной совместимости`remove()` блокировался бы до прихода нового элемента; в этом его роль в неблокирующих очередях`remove()` тихо вернул бы `null`, как `poll()`, потому что очередь пуста