🟢 Junior Level

ForkJoinPool — це спеціальний пул потоків для виконання задач, які можна розділити на підзадачі (принцип «розділяй і володарюй»).

На відміну від звичайного ThreadPoolExecutor (де кожен потік бере задачі із спільної черги), у ForkJoinPool у кожного потока своя черга (Deque) і механізм work-stealing — вільний потік «краде» задачі з хвоста черги зайнятого. Це знижує конкуренцію за чергу.

Зв’язок з parallel streams: Коли ви викликаєте parallelStream(), Java автоматично використовує ForkJoinPool для паралельної обробки.

// За замовчуванням використовує ForkJoinPool.commonPool()
list.parallelStream().map(this::process).collect(toList());

Розмір пулу: Зазвичай дорівнює кількість_ядер_CPU - 1.

🟡 Middle Level

Алгоритм Work-Stealing (Крадіжка роботи)

Головна фішка ForkJoinPool:

1. У кожного потока є своя двостороння черга (Deque) задач
2. Коли потік завершує свої задачі, він не засинає, а дивиться в черги “сусідів”
3. Він краде задачу з хвоста чужої черги

Це мінімізує конкуренцію і гарантує рівномірне завантаження всіх ядер.

Зв’язок з Parallel Streams

1. Source → Spliterator: Стрім розбиває дані на частини
2. Spliterator → ForkJoinTask: Кожна частина огортається в задачу
3. Execution: Задачі відправляються в пул
4. Combining: Результати підсумовуються через combiner

Common Pool

ForkJoinPool.commonPool() — статичний спільний пул:

• Розмір: Runtime.getRuntime().availableProcessors() - 1
• Навіщо -1? Один потік резервується для потоку, що викликає, який теж бере участь

🔴 Senior Level

LIFO vs FIFO черги

Внутрішні черги ForkJoin працюють за принципом:

• LIFO для “свого” потоку: останній елемент — найбільший (його ще не ділили), його вигідно обробити першим. Свіжі дані ще в кеші CPU.
• FIFO для “крадучих” потоків: забирають дрібні підзадачі з хвоста, щоб не конфліктувати з власником черги за голову deque.

ManagedBlocker

ForkJoinPool має інтерфейс ManagedBlocker. Якщо задача повідомляє, що збирається заблокуватися (I/O), пул може тимчасово створити новий потік, щоб не знижувати паралелізм. Стандартні паралельні стріми цей механізм майже не використовують.

Проблема ізоляції в Enterprise

В Spring Boot використання commonPool для всього — погана практика:

• Компонент А запустив важкий стрім → компонент Б гальмує
• Рішення: Кастомні ForkJoinPool для критично важливих задач

Task Granularity

Якщо задачі занадто дрібні — час на створення в ForkJoin перекриє користь. Якщо занадто великі — не працюватиме Work-Stealing. Stream API балансує це через Spliterator.

Діагностика

• -Djava.util.concurrent.ForkJoinPool.common.parallelism: Головний важіль управління
• ForkJoinPool.getCommonPoolParallelism(): Програмний спосіб дізнатись ліміт
• VisualVM/JConsole: Показують Steal Count. Якщо зростає — пул працює ефективно

---

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

Обов’язково знати:

• ForkJoinPool — пул потоків для задач типу «розділяй і володарюй», використовується паралельними стрімами
• На відміну від ThreadPoolExecutor, у кожного потока своя Deque-черга і алгоритм work-stealing
• Work-stealing: вільний потік «краде» задачу з хвоста чужої черги, мінімізуючи конкуренцію
• ForkJoinPool.commonPool() — статичний спільний пул, розмір = availableProcessors() - 1 (один потік резервується для потоку, що викликає)
• parallelStream() автоматично відправляє задачі в commonPool() через Spliterator
• У паралельному режимі «свій» потік працює за LIFO, «крадучий» — за FIFO (забирає дрібні підзадачі)
• В Spring Boot використання спільного commonPool для всього — антипатерн, потрібен кастомний ForkJoinPool

Часті уточнюючі запитання:

• Навіщо -1 у розмірі commonPool? — Потік, що викликає, сам бере участь в обробці, один потік резервується для нього
• Як ForkJoinPool знижує конкуренцію за чергу? — У кожного потока своя Deque; крадіжка з хвоста чужої черги не конфліктує з власником
• Як дізнатись поточний паралелізм commonPool програмно? — ForkJoinPool.getCommonPoolParallelism()
• Що таке ManagedBlocker і коли він потрібен? — Інтерфейс для задач, які можуть заблокуватися (I/O); пул створює тимчасовий потік. У стрімах майже не використовується

Червоні прапорці (НЕ говорити):

• «ForkJoinPool — те саме, що ThreadPoolExecutor» — у ForkJoinPool інша архітектура: work-stealing, per-thread Deque
• «commonPool завжди створює стільки потоків, скільки ядер» — на 1 менше, мінус потік, що викликає
• «Паралельний стрім створює свій пул» — він перевикористовує спільний ForkJoinPool.commonPool()
• «Можна ігнорувати Task Granularity» — занадто дрібні задачі = overhead на ForkJoinTask, занадто великі = немає work-stealing

Пов’язані теми:

• [[11. Як створити parallel stream]]
• [[12. Які потенційні проблеми можуть бути з паралельними стрімами]]
• [[10. Коли використовувати parallel streams]]
• [[9. Що таке паралельні стріми]]