Які потенційні проблеми можуть бути з паралельними стрімами

Паралельні стріми приховують за лаконічним API складну багатопотокову машинерію. Основні проблеми при їхньому необдуманому використанні:

🟢 Junior Level

Коротка відповідь для співбесіди (30 секунд)

Гонки даних та пошкодження структур (Race Conditions): мутація спільних несинхронізованих колекцій (наприклад, ArrayList.add()) призводить до втрати даних або ArrayIndexOutOfBoundsException.
Деградація швидкості на малих даних: накладні витрати на поділ завдань у Spliterator та координацію потоків перевищують час самих обчислень (однопотоковий цикл for виявляється в десятки разів швидшим).
Блокування спільного пулу потоків (Thread Starvation): виконання I/O-операцій (HTTP, JDBC) паралізує спільний ForkJoinPool.commonPool() усієї JVM.
Непередбачуваний порядок: метод forEach() обробляє елементи хаотично залежно від розподілу за ядрами CPU.

Небезпечні антипатерни на Java 21

import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
import java.util.stream.IntStream;

public class ParallelStreamProblemsDemo {

    public static void main(String[] args) {
        // ❌ Проблема 1: Мутація несинхронізованого стану (Гонка даних)
        List<Integer> unsafeList = new ArrayList<>();
        IntStream.range(0, 10_000).parallel().forEach(unsafeList::add);
        // unsafeList.size() майже напевно буде меншим за 10 000 (втрата елементів)!

        // ✅ Рішення: Використання collect() або toList()
        List<Integer> safeList = IntStream.range(0, 10_000).parallel().boxed().toList();

        // ❌ Проблема 2: Сповільнення на примітивних операціях
        long start = System.nanoTime();
        int sum = IntStream.rangeClosed(1, 100).parallel().sum(); // Оверхед ForkJoin!
        long parallelDuration = System.nanoTime() - start;

        start = System.nanoTime();
        int seqSum = IntStream.rangeClosed(1, 100).sum(); // Швидше в рази
        long seqDuration = System.nanoTime() - start;

        System.out.printf("Паралельно: %d нс, Послідовно: %d нс%n",
            parallelDuration, seqDuration);
    }
}

🟡 Middle Level

Архітектурні пастки продуктивності

1. Невідповідні джерела даних (Bad Spliterators)

В ArrayList або масиві поділ відбувається за $O(1)$ за індексами.
У LinkedList поділ вимагає $O(N)$ кроків за посиланнями next. Накладні витрати на поділ знищують будь-який виграш від розпаралелювання.
У генераторах виду Stream.iterate(0, i -> i + 1) кожен наступний елемент функціонально залежить від попереднього, через що потоки блокуються і шикуються в чергу.

2. Витратні операції порядку (Encounter Order Contention)

Операції, що залежать від вихідного порядку елементів, перетворюються в паралельному стрімі на важкі бар’єри синхронізації:

limit(n) та skip(n): щоб повернути перші $n$ елементів, рантайм зобов’язаний координувати потоки та відкидати результати обчислень правих гілок ForkJoinPool, навіть якщо вони вже завершилися.
findFirst(): потік, що знайшов елемент у правій гілці, зобов’язаний чекати, чи не знайде ліва гілка елемент раніше. (Рішення: використовувати findAny()).
sorted(): вимагає повної матеріалізації всіх елементів із усіх потоків у єдиний проміжний масив перед початком сортування.

Проблема втрати контексту (Security, Transactions, MDC)

Потоки пулу ForkJoinPool.commonPool() не успадковують контекст викликаючого потоку:

Spring @Transactional: транзакція прив’язана до потоку через ThreadLocal. Усередині паралельного стріма код виконується у воркерах пулу, де транзакція відсутня, що призводить до неконсистентних читань або TransactionRequiredException.
SecurityContextHolder: контекст автентифікації Spring Security втрачається в дочірніх потоках.
Логування через SLF4J MDC: ідентифікатори запиту (traceId, userId) не потрапляють у логи воркерів паралельного стріма.

🔴 Senior Level

Голодування пулу: Starvation of `ForkJoinPool.commonPool()`

Усі компоненти JVM (якщо явно не задано іншого виконавця) використовують спільний статичний пул потоків:

CompletableFuture.supplyAsync(supplier) (без зазначення Executor).
Усі виклики parallelStream().

                  ForkJoinPool.commonPool() [Cores - 1]
                                    │
    ┌───────────────────────────────┴───────────────────────────────┐
    │                                                               │
Task 1: HTTP Call (Завис на 5с)                                 Task 2: JDBC Call (Завис на 3с)
    ▼                                                               ▼
Worker Thread 1 (Заблокований)                                  Worker Thread 2 (Заблокований)

               ===> УСІ ПУЛИ ВИЧЕРПАНІ, ЧЕРГА ЗАБИТА <===
               Нові завдання та CompletableFuture стають у deadlock!

Senior Best Practice: Категорично заборонено виконувати блокуючий I/O всередині паралельних стрімів. Для завдань введення-виведення в сучасних версіях Java (21+) слід використовувати Virtual Threads (Executors.newVirtualThreadPerTaskExecutor()).

Поведінка при винятках: переривання паралельних завдань

Якщо одне із завдань у паралельному стрімі викидає неперевірений виняток (RuntimeException):

Виняток перехоплюється внутрішнім вузлом CountedCompleter.
Завдання переходить у стан EXCEPTIONAL.
Решті завдань, що ще працюють в інших потоках, виставляється статус скасування (cancel), проте JVM не перериває їх миттєво через Thread.interrupt() (за винятком випадків, коли код усередині лямбди явно опитує прапорець переривання).
Термінальна операція стріма огортає вихідну помилку і прокидає її назовні викликаючому потоку. Якщо кілька потоків викинули винятки, один стає основним, а решта додаються до списку пригнічених (Suppressed Exceptions).

False Sharing (Хибне розділення кеш-ліній): Якщо потоки записують у сусідні елементи масиву, що потрапляють в один 64-байтний рядок процесорного кешу (Cache Line), процесор безперервно інвалідує кеші ядер за протоколом когерентності MESI. Це може сповільнити код у десятки разів порівняно з послідовним виконанням.
Memory Bandwidth Bottleneck: При простих обчисленнях над величезними обсягами даних вузьким місцем стає не тактова частота CPU, а пропускна здатність шини пам’яті до DRAM. Кілька ядер конкурують за одну шину пам’яті та простоюють в очікуванні даних.

🎯 Шпаргалка для інтерв’ю

30-секундна відповідь

«Основні проблеми паралельних стрімів: по-перше, вичерпання спільного пулу ForkJoinPool.commonPool() за наявності блокуючого введення-виведення. По-друге, сповільнення на малих колекціях і структурах із поганим сплітом (LinkedList, iterate). По-третє, втрата ThreadLocal-контекстів (Spring Transactions, Security, MDC) у потоках пулу. По-четверте, гонки даних при мутації спільного стану замість використання чистих колекторів. Для операцій, залежних від порядку (limit, skip, findFirst), паралелізм створює важкі бар’єри синхронізації.»

Таблиця проблем і рішень

Проблема	Причина	Правильне рішення
Гонка даних	Мутація зовнішніх змінних (`list.add()`)	Використовувати `collect()`, `toList()`, `reduce()`
Сповільнення коду	Мала кількість елементів ($N \times Q < 10\,000$)	Використовувати стандартний однопотоковий `stream()`
Падіння сервісу	Блокуючий I/O у `commonPool`	Використовувати Virtual Threads (Java 21+)
Жахливий спліт	Використання `LinkedList` або `Stream.iterate`	Використовувати `ArrayList`, масиви, `IntStream.range`
Втрата контексту	`ThreadLocal` не передається у воркери	Явна передача контексту або відмова від паралельного стріма
Бар’єри порядку	`limit()`, `skip()`, `findFirst()`	Використовувати `.unordered()`, `findAny()`

Топ-4 каверзних запитання на інтерв’ю

1. Що станеться, якщо одна з паралельних гілок у `parallelStream` викине `RuntimeException`?

Стрім завершиться аварійно, прокинувши виняток у потік, що викликав термінальну операцію. Батьківське завдання CountedCompleter скасує незапущені підзавдання. Якщо кілька паралельних потоків одночасно викинуть винятки, один із них стане основним викинутим винятком, а решта будуть прикріплені до нього через механізм addSuppressed().

2. Чому в коді зі Spring `@Transactional` категорично небезпечно використовувати `parallelStream()`?

Механізм декларативних транзакцій Spring зберігає об’єкт транзакції та з’єднання з БД у ThreadLocal викликаючого потоку. У паралельному стрімі код лямбд виконується потоками пулу ForkJoinPool.commonPool-worker. У цих потоках ThreadLocal чистий, тому операції з базою даних або виконаються поза транзакцією (автокоміт), або впадуть із помилкою відсутності транзакційного контексту.

3. Чому виклик `.unordered()` перед `.limit(5)` у `parallelStream()` може прискорити роботу в рази?

Якщо стрім упорядкований, limit(5) зобов’язаний повернути рівно перші 5 елементів згідно з порядком джерела, що змушує праві гілки чекати завершення лівих і скидати обчислені результати. Виклик .unordered() дозволяє стріму повернути будь-які перші 5 елементів, які першими встигли обробити паралельні потоки, знімаючи міжпотокове блокування.

4. Як `parallelStream` поводиться в Docker-контейнерах із лімітом CPU (наприклад, 0.5 або 1 core)?

У сучасних версіях JVM (Java 17/21) рантайм визначає доступні процесори через cgroups. Якщо ліміт CPU дорівнює 1 ядру, commonPool отримає розмір 1 - 1 = 0 робочих потоків. Стрім буде виконуватися тільки викликаючим потоком, але з повним оверхедом на поділ завдань Spliterator та створення об’єктів ForkJoinTask, працюючи помітно повільніше за звичайний цикл.

Типові помилки та Red Flags

🚩 Запис у несинхронізовану колекцію з паралельного стріма (parallelStream().forEach(res::add)).
🚩 Виклик мікросервісів або SQL-запитів усередині parallelStream().
🚩 Спроба використовувати parallelStream() для обробки LinkedList.
🚩 Очікування збереження контексту авторизації або транзакції Spring усередині паралельних гілок стріма.