🟢 Junior Level

Параллельные стримы — не всегда делают код быстрее. Вот основные проблемы:

1. Блокировка общего пула потоков Все параллельные стримы делят один ForkJoinPool.commonPool(). Если один стрим делает долгий HTTP-запрос — все остальные ждут.

2. Медленнее обычного цикла Для маленьких списков параллельный стрим будет медленнее из-за расходов на разделение задач и объединение результатов. overhead на ForkJoinTask для списка из 100 элементов может составить ~50мкс, тогда как простой цикл — ~1мкс. Параллелизм окупается от ~10,000 элементов (правило N × Q > 10,000).

3. Проблемы с потокобезопасностью

// КАТАСТРОФА — ArrayList не потокобезопасен
List<Integer> list = new ArrayList<>();
numbers.parallelStream().forEach(list::add);

Можете получить ConcurrentModificationException или потерю данных.

4. Непредсказуемый порядок parallelStream().forEach() обрабатывает элементы в случайном порядке.

🟡 Middle Level

Race Conditions

Лямбды в стримах должны быть stateless (без состояния):

// ПЛОХО — мутация внешней переменной
AtomicInteger counter = new AtomicInteger();
numbers.parallelStream().forEach(n -> counter.incrementAndGet());

100 потоков, конкурирующих за один AtomicInteger, создают contention — стрим станет медленнее обычного цикла.

Неэффективные операции в параллелизме

• limit() и skip(): Требуют синхронизации между потоками
• sorted(): Параллельная сортировка эффективна только на очень больших объемах
• findFirst(): Заставляет ждать результата от первого потока (используйте findAny())

Потеря локальности данных

CPU любит последовательное чтение (L1/L2 cache prefetching — CPU заранее подгружает соседние байты в быстрый кэш). Когда потоки читают из разных участков памяти, CPU не может предсказать адрес — кэш промах, процессор ждёт данные из RAM (100+ тактов).

ThreadLocal Dangers

В general case не используйте ThreadLocal внутри параллельного стрима — воркеры ForkJoinPool переиспользуются между задачами. Если контролируете кастомный ForkJoinPool и очищаете ThreadLocal в finally — допустимо.

🔴 Senior Level

Starvation Common Pool

Если компонент А запустил тяжелый стрим, компонент Б будет тормозить. В Enterprise-приложениях (Spring Boot) это критично.

Решение: Изоляция через кастомные ForkJoinPool:

ForkJoinPool isolatedPool = new ForkJoinPool(8);
isolatedPool.submit(() -> stream.parallel()...).get();

False Sharing

При обновлении соседних элементов в массиве примитивов потоки инвалидируют кэш-линии друг друга в CPU — деградация производительности до уровня одного ядра и ниже.

Overhead breakdown

1. Разделение данных (Splitting)
2. Создание объектов задач (Task allocation)
3. Переключение контекста между ядрами
4. Слияние результатов (Merging/Combining)

Диагностика

• -Djava.util.concurrent.ForkJoinPool.common.parallelism=0: Временно отключите параллелизм для тестов
• Thread Dumps: Если приложение “зависло” — проверьте commonPool. Если все потоки в WAITING на сетевых вызовах — найдена проблема
• JMH Benchmarking: Единственный способ доказать пользу параллелизма

---

🎯 Шпаргалка для интервью

Обязательно знать:

• Параллельные стримы делят один ForkJoinPool.commonPool() — один долгий запрос блокирует все остальные
• overhead Fork/Join окупается от ~10 000 элементов (правило N x Q > 10 000)
• parallelStream().forEach() обрабатывает элементы в случайном порядке — для упорядоченного результата используйте forEachOrdered()
• Изменение внешних переменных в параллельном стриме ведёт к ConcurrentModificationException и race conditions
• limit(), skip(), findFirst() требуют синхронизации между потоками и неэффективны
• CPU cache locality теряется при параллелизме — потоки читают из разных участков памяти, кэш-промахи 100+ тактов
• В Spring Boot общий commonPool — критическая проблема: компонент А тормозит компонент Б

Частые уточняющие вопросы:

• Когда параллельный стрим медленнее обычного цикла? — На малых данных (< 10K элементов) и при мутации внешних переменных
• Как изолировать нагрузку параллельного стрима? — Запустить через кастомный ForkJoinPool: pool.submit(() -> stream.parallel()...).get()
• Чем заменить findFirst() в параллельном режиме? — Использовать findAny() — он не требует синхронизации
• Как диагностировать проблемы с commonPool? — Отключить параллелизм через системное свойство -Djava.util.concurrent.ForkJoinPool.common.parallelism=0

Красные флаги (НЕ говорить):

• «Параллельный стрим — это всегда быстрее» — overhead и contention могут сделать его в разы медленнее
• «Можно использовать ArrayList в параллельном forEach» — ArrayList не потокобезопасен, потеря данных гарантирована
• «ThreadLocal безопасен в параллельном стриме» — воркеры переиспользуются между задачами, ThreadLocal «утечёт»
• «Параллельный стрим сам решит, сколько потоков использовать» — он использует один shared commonPool

Связанные темы:

• [[Как создать parallel stream]]
• [[Что такое ForkJoinPool и как он связан с parallel streams]]
• [[Можно ли изменять состояние внешних переменных в Stream операциях]]
• [[Почему следует избегать побочных эффектов в Stream]]
• [[Когда использовать parallel streams]]