Краткий ответ

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

Безопаснее позволить Stream API самостоятельно собирать частичные результаты через collect, не используя общий список из внешней области.

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

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

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

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

ArrayList хранит элементы во внутреннем массиве и изменяет размер списка при добавлении. Его методы add не синхронизированы, поэтому одновременные вызовы из разных потоков не образуют безопасную последовательность операций.

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

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

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

import java.util.List;
import java.util.stream.Collectors;
import java.util.stream.IntStream;

List<Integer> result = IntStream.range(0, 10_000)
        .parallel()
        .boxed()
        .collect(Collectors.toList());

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

Синхронизированный список может устранить гонку при отдельных вызовах add, но не всегда является хорошим решением: все записи будут конкурировать за одну блокировку, а производительность может оказаться хуже последовательной обработки. Потокобезопасная коллекция также не делает произвольную последовательность нескольких операций атомарной.

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

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

Сервис преобразовывал несколько миллионов записей и добавлял результаты во внешний ArrayList из параллельного forEach. На тестовых данных ошибка проявлялась нестабильно: итоговый размер списка иногда был меньше ожидаемого, а повторный запуск давал другой результат.

Рассматривались три варианта:

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

Выбрали третий вариант, поскольку операция преобразования не зависела от внешнего состояния, а порядок элементов был значим. Результат стал детерминированным для упорядоченного источника, а конкуренция за один список исчезла; после измерений параллельную обработку оставили только для достаточно крупных наборов данных.

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

1. Всегда ли collect(Collectors.toList()) в параллельном стриме создаёт потокобезопасный список?

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

2. Почему добавление через forEach может изменить порядок даже после замены ArrayList на потокобезопасную коллекцию?

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

3. Почему отсутствие внешнего списка не гарантирует корректность параллельного стрима?

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