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

Collector разделяет тип аккумулятора A, в который постепенно накапливаются данные, и тип итогового результата R, который возвращается вызывающему коду. Это позволяет сначала эффективно собирать элементы в изменяемую структуру, а затем преобразовывать её в другой вид: например, в неизменяемый список, карту или агрегированное значение.

Ключевую роль выполняет finisher — функция, преобразующая A в R. Если результат уже является тем же объектом и типом, что и аккумулятор, может применяться характеристика IDENTITY_FINISH, позволяющая не выполнять отдельное преобразование.

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

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

Collector оформляет эту задачу в виде контракта: как создать контейнер, добавить в него элемент, объединить частичные контейнеры и получить итоговый результат. Разделение A и R позволило не связывать эффективную внутреннюю структуру накопления с публичным типом результата.

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

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

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

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

У коллектора есть два связанных типа:

A — тип изменяемого промежуточного контейнера;
R — тип результата, который возвращает терминальная операция collect.

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

Минимальный пример преобразует изменяемый промежуточный список в неизменяемый результат:

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

List<String> result = Stream.of("A", "B", "C")
    .collect(Collectors.collectingAndThen(
        Collectors.toList(),
        List::copyOf
    ));

Collectors.toList() накапливает элементы во внутреннем списке. collectingAndThen после завершения накопления вызывает List.copyOf, поэтому итоговый объект отличается по назначению от промежуточного контейнера: он предназначен для чтения и не допускает структурных изменений.

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

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

Разделение A и R не делает промежуточный контейнер автоматически потокобезопасным. Корректность параллельного сбора обеспечивается всем контрактом коллектора: аккумулятор должен корректно обрабатывать элементы в своём частичном контейнере, а combiner — корректно объединять такие контейнеры.

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

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

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

вернуть результат toList() напрямую — просто, но контракт изменяемости такого результата не следует считать гарантированным;
вручную скопировать список после collect — надёжно, но логика преобразования оказывается отделена от описания самого сбора;
применить collectingAndThen с преобразованием в неизменяемый список — аккумуляция и финальное преобразование явно описаны в одном коллекторе.

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

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

Вопрос: Может ли finisher изменить тип результата без изменения типа аккумулятора?

Ответ: Да. Например, аккумулятором может быть ArrayList<String>, а результатом — List<String>, неизменяемая обёртка или вообще строка. Тип A нужен реализации коллектора, а тип R — пользователю терминальной операции. Это позволяет выбирать внутреннюю структуру по эффективности, не делая её частью внешнего контракта.
Вопрос: В какой момент при параллельном сборе применяется finisher?

Ответ: В общем случае после того, как частичные контейнеры накоплены и объединены в итоговый аккумулятор. Finisher не должен предполагать, что ему передадут один из исходных частичных контейнеров или что он будет вызван для каждого такого контейнера. Если у коллектора есть IDENTITY_FINISH, отдельный вызов finisher может быть не нужен, поскольку аккумулятор уже считается итогом.
Вопрос: Почему collectingAndThen обычно несовместим с характеристикой IDENTITY_FINISH?

Ответ: Потому что collectingAndThen добавляет реальное преобразование после накопления. Даже если финальная функция иногда возвращает тот же объект или выполняется дёшево, сам коллектор больше не обещает, что аккумулятор без преобразований является итоговым результатом. Поэтому реализация должна учитывать finisher и не может безопасно трактовать аккумулятор как готовый R только на основании внутреннего типа.