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

Для большинства стандартных потоков, созданных из коллекций, источник связывается с потоком поздно: изменения коллекции, выполненные до начала обхода, обычно могут попасть в результат. Это свойство определяется реализацией источника и его Spliterator, поэтому не является универсальной гарантией для любого Stream.

Изменять несинхронизированную коллекцию уже во время обхода нельзя: результат может быть непредсказуемым, а реализация может выбросить ConcurrentModificationException.

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

Stream API появился в Java 8, чтобы отделить описание обработки данных от способа их последовательного или параллельного обхода. Для этого Stream использует источник и Spliterator, который отвечает за получение элементов и, при необходимости, их разбиение на части.

Ленивое выполнение и позднее связывание позволяют не начинать работу с источником при создании конвейера. Это уменьшает преждевременное копирование данных и даёт источнику возможность подготовить актуальное состояние непосредственно перед обходом.

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

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

Особенно опасна модификация коллекции во время выполнения терминальной операции. В таком случае элементы могут быть пропущены или обработаны повторно, а fail-fast-реализация может обнаружить структурное изменение и выбросить исключение.

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

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

Это не означает создания согласованного снимка. Поток читает тот же источник, а не независимую копию. Если источник изменяется после начала обхода, корректность зависит от его контракта: для обычных коллекций безопасной согласованности нет, а обнаружение ошибки механизмом fail-fast является лишь защитой от некоторых нарушений, а не способом синхронизации.

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

Минимальный пример:

import java.util.*;

List<String> names = new ArrayList<>(List.of("Аня"));
var stream = names.stream();
names.add("Борис");

System.out.println(stream.toList());

В типичной реализации ArrayList результатом будет список с обоими именами: обход начинается после добавления элемента. Однако этот пример не следует трактовать как универсальную гарантию для любого источника Stream.

Копия повышает предсказуемость, но требует дополнительной памяти и времени. Использование concurrent-коллекции может обеспечить специальные гарантии безопасного параллельного доступа, но обычно не создаёт единого атомарного снимка и может усложнить понимание результата.

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

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

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

Для отчёта выбран явный снимок перед построением конвейера. Это обосновано требованием воспроизводимости: отчёт должен описывать состояние на момент формирования, а небольшая цена копирования приемлема по сравнению с неоднозначным результатом.

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

Позднее связывание означает автоматический снимок данных?

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

Можно ли считать ConcurrentModificationException гарантированным результатом изменения коллекции во время обхода?

Нет. Fail-fast-поведение предназначено для раннего обнаружения части ошибок и обычно не является абсолютной гарантией. Исключение возможно, но возможны также неполный, неожиданный или зависящий от реализации результат.

Достаточно ли сделать Stream параллельным, чтобы изменения источника стали безопасными?

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