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

В стандартной реализации Java задачи параллельного Stream обычно выполняются через общий ForkJoinPool, доступный как ForkJoinPool.commonPool(). Однако это не означает, что каждый элемент получает отдельный поток: источник разделяется на части, а задачи обрабатываются рабочими потоками пула, иногда с участием потока, инициировавшего операцию.

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

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

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

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

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

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

Если обработчик элемента блокируется на базе данных, HTTP-сервисе или файловой операции, рабочие потоки могут надолго оказаться занятыми. Это способно увеличить задержки несвязанных задач и создать впечатление, что параллельный Stream «завис» или неожиданно замедлился.

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

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

Минимальная иллюстрация:

import java.util.stream.IntStream;

IntStream.range(0, 8)
    .parallel()
    .forEach(i ->
        System.out.println(i + " -> " + Thread.currentThread().getName())
    );

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

Вызов parallel() не создаёт отдельный исполнитель и не даёт Stream собственного лимита потоков. Настройка общего ForkJoinPool влияет на множество потребителей сразу, поэтому изменение его глобальных параметров ради одной операции требует осторожности.

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

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

Сервис параллельно обрабатывает большой массив изображений, но одновременно использует общий ForkJoinPool для других вычислений. Быстрый вариант — вызвать parallel() напрямую: он прост и не требует дополнительной инфраструктуры, но его задачи будут конкурировать с остальными пользователями общего пула.

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

Третий вариант — вынести обработку в явно управляемый специализированный исполнитель и контролировать очередь, размер пула и завершение задач. Для CPU-зависимой обработки это обычно даёт лучшую изоляцию и предсказуемость; выбранный вариант оправдан, если нагрузка критична для сервиса и требует независимого управления ресурсами.

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

Гарантирует ли параллельный Stream использование только потоков ForkJoinPool?

Нет, такой вывод слишком категоричен. Реализация использует ForkJoinPool для выполнения параллельных задач, но поток, запускающий терминальную операцию, также может участвовать в работе. Кроме того, спецификация Stream API не обещает конкретные имена потоков, их точное количество или детальную схему планирования.
Можно ли передать собственный Executor непосредственно в операцию параллельного Stream?

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

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