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

Код небезопасен: mutable-объект StringBuilder используется как identity в reduce. Контракт редукции требует, чтобы операции были ассоциативными, не изменяли неподходящие общие состояния, а identity корректно работал для каждой частичной редукции. В параллельном стриме один и тот же изменяемый объект может участвовать в нескольких частичных вычислениях, поэтому результат не гарантирован.

Для изменяемого контейнера следует использовать collect, где supplier создаёт отдельный контейнер для каждой части обработки, а затем контейнеры объединяются.

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

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

Исходная идея reduce предполагает значение результата, а не рабочий изменяемый контейнер. Для построения контейнеров вроде списка, карты или StringBuilder в Stream API предусмотрен collect: он явно разделяет создание контейнера, добавление элементов и объединение контейнеров.

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

В последовательном режиме такой код может выглядеть рабочим: один StringBuilder постепенно получает все значения. Но вызов .parallel() меняет требования к операциям редукции.

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

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

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

У перегруженного варианта reduce используются три компонента: identity, аккумулятор BiFunction<U, T, U> и объединитель BinaryOperator<U>. Для корректности identity должен быть нейтральным значением, а аккумулятор и объединитель должны удовлетворять требованиям, позволяющим менять порядок группировки вычислений.

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

Для контейнеров используется collect:

String result = IntStream.rangeClosed(1, 1000)
    .parallel()
    .boxed()
    .collect(
        StringBuilder::new,
        (builder, value) -> builder.append(value).append(','),
        StringBuilder::append
    )
    .toString();

Здесь StringBuilder::new создаёт контейнеры для частичных вычислений, аккумулятор добавляет элементы в локальный контейнер, а combiner объединяет готовые контейнеры. Такой подход соответствует назначению collect, хотя порядок элементов при параллельной обработке нужно оценивать отдельно: для упорядоченного источника корректный collector без характеристики UNORDERED должен учитывать encounter order при объединении.

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

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

В отчётном сервисе разработчик заменил последовательный стрим на параллельный, чтобы ускорить формирование CSV из нескольких миллионов чисел. Он оставил reduce с одним StringBuilder, потому что последовательные тесты выдавали правильный текст.

Рассматривались три варианта. Синхронизировать операции над общим StringBuffer можно было бы с точки зрения отдельных вызовов, но это создаёт конкуренцию и не исправляет ошибочную модель mutable identity. Использовать collect с локальными StringBuilder корректнее, но объединение больших строк всё равно требует ресурсов. Оставить последовательную обработку проще, даёт стабильный порядок и часто оказывается быстрее для форматирования.

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

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

Разве проблема исчезнет, если заменить StringBuilder на StringBuffer?

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

Почему обычная конкатенация строк через reduce концептуально безопаснее?

Строки в Java неизменяемы. При операции вроде (left, value) -> left + value создаётся новое значение, а исходные частичные результаты не изменяются. Если операция объединения сохраняет ассоциативность, реализация может менять группировку вычислений без разрушения состояния. Однако конкатенация строк может быть дорогой из-за создания множества промежуточных объектов, поэтому для производительности применяют специализированные collectors или последовательный StringBuilder.

Можно ли использовать collect, если источник упорядочен, но результат нужен в любом порядке?

Можно, но нужно явно оценить требования. Если порядок не важен, collector может иметь характеристику UNORDERED, а источник или pipeline могут быть переведены в режим, допускающий игнорирование encounter order; это иногда упрощает параллельную обработку. Если порядок важен, нельзя рассчитывать на произвольное объединение контейнеров: combiner и весь collector должны сохранять требуемый порядок.