Какой порядок элементов гарантирован при обработке упорядоченного параллельного стрима через обычный forEach?

Никакой порядок не гарантирован. Даже если исходный источник имеет порядок следования, обычный forEach в параллельном стриме может передавать элементы потребителю в любом порядке; для сохранения порядка используют forEachOrdered, обычно жертвуя частью параллелизма.

Исторический контекст

Stream API появился в Java 8 для декларативной обработки последовательностей данных и отделения описания операции от способа её выполнения. Одной из целей было дать единый механизм, который может обрабатывать данные как последовательно, так и параллельно.

Параллельная обработка разбивает поток на части, выполняет их независимо и затем координирует результат. Поэтому сохранение исходного порядка требует дополнительной синхронизации и ожидания готовности предыдущих частей.

Постановка проблемы

Упорядоченный источник, например список, имеет определённый порядок следования элементов. Однако вызов parallelStream допускает одновременную обработку разных частей, а forEach не обязан передавать результаты потребителю в порядке источника.

Если в обработчике выполняются вывод в журнал, отправка сообщений, запись событий или изменение внешнего состояния, фактический порядок может отличаться от исходного. Код может выглядеть корректно и при этом давать разные результаты при разных запусках или нагрузке.

Подробное решение

forEach предназначен для применения действия к каждому элементу без требования сохранить encounter order — порядка следования, определённого источником. В параллельном стриме рабочие потоки обрабатывают фрагменты независимо, поэтому более поздний элемент может быть передан обработчику раньше более раннего.

forEachOrdered требует соблюдать encounter order, если он существует у источника. Реализация вынуждена координировать результаты параллельных фрагментов и не выдавать очередной элемент до завершения необходимых предшествующих частей. Это сохраняет порядок, но может уменьшить пропускную способность и увеличить задержку.

import java.util.List;

public class Demo {
    public static void main(String[] args) {
        List<Integer> values = List.of(1, 2, 3, 4, 5);

        values.parallelStream().forEach(System.out::println);
        values.parallelStream().forEachOrdered(System.out::println);
    }
}

В первом вызове числа могут быть напечатаны в любом порядке. Во втором вызове для этого упорядоченного источника будет сохранён порядок от 1 до 5.

Если порядок не нужен, forEach обычно предоставляет реализации больше свободы для параллельного выполнения. Если порядок является частью бизнес-логики, его следует явно сохранить или отказаться от параллельной обработки, если цена координации делает её невыгодной.

Нельзя автоматически считать параллельный стрим более быстрым. Для небольших объёмов данных стоимость разбиения, планирования задач и координации может превысить выигрыш от нескольких потоков.

Ситуация из практики

Сервис читает упорядоченный список событий и параллельно формирует сообщения для внешней системы. Вариант с обычным forEach обеспечивает высокую степень параллелизма, но сообщения приходят в непредсказуемом порядке, что нарушает зависимость между событиями.

Вариант с forEachOrdered сохраняет порядок, но часть преимуществ параллельного выполнения теряется: готовые результаты могут ожидать более ранние элементы. Вариант с последовательным стримом проще и предсказуемее, но не использует параллельные вычисления.

Рациональное решение — не отправлять внешние сообщения непосредственно из параллельного стрима. Сначала можно независимо вычислить данные для каждого события, затем получить упорядоченный результат и выполнить последовательную отправку. Это сохраняет параллелизм дорогой чистой обработки и отдельно контролирует порядок побочного действия.

Что кандидаты часто упускают

1. Всегда ли forEachOrdered полностью устраняет недетерминизм?

   Нет. Он упорядочивает прохождение элементов относительно encounter order, если такой порядок определён источником. Для неупорядоченного источника, например множества без гарантированного порядка, требовать конкретную последовательность нельзя.

   Кроме того, порядок вызовов обработчика не делает сам обработчик потокобезопасным во всех остальных аспектах. Если обработчик обращается к общему изменяемому состоянию, проблема гонок может сохраняться независимо от порядка элементов.

2. Почему forEachOrdered может снизить производительность параллельного стрима?

   Независимое вычисление частей ещё может выполняться параллельно, но выдача результатов должна быть согласована с порядком источника. Поэтому готовый результат одного фрагмента иногда ожидает завершения предшествующего фрагмента.

   Чем сильнее последующая операция зависит от строгого порядка и чем дороже координация между частями, тем меньше потенциальная выгода параллелизма. Для простых или небольших задач последовательная обработка может оказаться быстрее.

3. Можно ли использовать forEach в параллельном стриме для записи в общий поток вывода?

   Сам вызов forEach не гарантирует корректную логическую последовательность записей. Даже если конкретный поток вывода допускает одновременные вызовы методов, строки могут появляться не в порядке источника, а сложный общий объект может требовать дополнительной синхронизации.

   Если важны и целостность, и порядок, безопаснее сначала собрать результаты без побочных эффектов, затем обработать их последовательно. Если порядок не важен, общий ресурс всё равно должен иметь документированный потокобезопасный способ доступа; полагаться только на параллельный стрим нельзя.