Stream API

Stream — это конвейер над последовательностью элементов, а не контейнер, который их хранит. У него есть источник (коллекция или массив), промежуточные операции вроде filter и map и одна терминальная операция вроде collect. В отличие от цикла он описывает, что вычислить, а не как итерировать, и он никогда не меняет свой источник — он даёт новые результаты.

Промежуточная операция вроде filter или map возвращает другой Stream, поэтому она лишь добавляет стадию в конвейер. Терминальная операция вроде collect или count возвращает не-stream результат и именно она реально запускает конвейер. До этого терминального вызова не вычисляется ничего — промежуточные стадии отложены по замыслу.

Это ошибка компиляции, а не рантайма. map(authService::findClient) оборачивает уже-Optional результат, давая Optional<Optional<Client>>. Поэтому в следующем map client — это Optional<Client>, а не Client, и передача его в createResponse(Client) не проходит проверку типов. Исправьте использованием flatMap для findClient: flatMap разворачивает один уровень, давая Optional<Client>, поэтому следующий map получает настоящий Client.

parallelStream разбивает источник и выполняет стадии в общем ForkJoinPool (по числу ядер), затем объединяет частичные результаты. Он ускоряет CPU-bound работу на больших разбиваемых источниках, но вредит малым или I/O-bound. Он молча ломает корректность, когда reduce использует не-нейтральный seed или неассоциативный аккумулятор либо когда лямбда меняет общее состояние — каждый поток заново применяет seed, а порядок теряется.

Stream API обрабатывает последовательность элементов декларативно как конвейер: источник, промежуточные операции вроде filter и map и терминальную операцию вроде collect. Промежуточные операции отложенные — они строят конвейер, не итерируя; выполнение запускает только терминальная операция, прогоняя через него каждый элемент. Stream может также работать параллельно по потокам.

groupingBy(classifier) применяет классификатор к каждому элементу и собирает элементы в Map<K, List<T>> с ключом по его результату. Двухаргументный groupingBy(classifier, downstream) пропускает каждую корзину через второй коллектор вместо списка элементов, поэтому groupingBy(Order::status, counting()) даёт Map<Status, Long> со счётчиками за один проход: orders.stream().collect(groupingBy(Order::status, counting())).

reduce — неизменяемая свёртка: он применяет BinaryOperator к identity и текущему значению, порождая на каждом шаге новое значение. collect — изменяемая свёртка: supplier создаёт контейнер, аккумулятор вкладывает каждый элемент, а комбайнер сливает два контейнера. Берите reduce для значения вроде суммы или максимума; берите collect, когда результат — контейнер, ведь свёртка String на каждый элемент выделяет O(n) мусора.

Строит его Collector.of(supplier, accumulator, combiner, finisher). Supplier создаёт свежий изменяемый контейнер на воркера, аккумулятор вкладывает один элемент, комбайнер сливает два контейнера — это и делает коллектор безопасным в параллели, — а finisher превращает контейнер в результат. Для topN контейнер — min-heap: кладём элемент, выбрасываем наименьший, как только их больше n, и сортируем уцелевших в finisher. Память остаётся O(n).

Отложенность тянет элементы по одному, поэтому короткозамыкающий терминал — findFirst, anyMatch, allMatch — прекращает тянуть, как только ответ решён: filter(p).findFirst() на миллионе элементов проверяет p лишь до первого совпадения. Это же делает бесконечный Stream.iterate пригодным под limit. Загвоздка в порядке: на параллельном упорядоченном stream findFirst обязан вернуть первое по порядку появления совпадение, в отличие от findAny.

Stream — не контейнер: он держит spliterator источника и стадии конвейера и обходит источник ровно один раз. Конвейер несёт флаг «связан или израсходован», который выставляет терминальная операция, поэтому любая следующая операция бросает IllegalStateException. Ничего не буферизовано для повтора — spliterator не перемотать. Чтобы обойти дважды, соберите stream заново из источника или держите Supplier<Stream<T>>.

Двухаргументный toMap(keyMapper, valueMapper) не знает правила для двух элементов, попавших на один ключ, поэтому второй сотрудник из Sales роняет его. Возьмите трёхаргументную перегрузку и дайте ей функцию слияния — toMap(Employee::department, Employee::salary, Integer::sum) — она сворачивает столкнувшиеся значения вместо падения. Эквивалент — groupingBy(Employee::department, summingInt(...)).

Gatherer (финализирован в Java 24, JEP 485) — своя промежуточная операция, аналог Collector для середины конвейера, подключаемый через stream.gather(g). Он собран из initializer, integrator, необязательного combiner и finisher, поэтому умеет хранить состояние между элементами, выдавать ноль, один или много выходных элементов на один входной и коротко замыкать источник. Collector же сворачивает лишь один раз — на терминальном шаге.