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

ForkJoinTask.join() в рабочем потоке ForkJoinPool может не просто блокировать поток: пока нужная подзадача не завершена, worker способен выполнять другие доступные задачи или помогать довести целевую задачу до завершения. Поэтому корректно построенное дерево fork/join обычно не приводит к простому истощению пула, однако это не делает произвольные блокирующие операции и циклические зависимости безопасными.

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

Модель Fork/Join появилась для эффективного выполнения рекурсивно разделяемых вычислений: сортировки, обхода деревьев, обработки диапазонов и других задач типа «разделить и объединить». Обычный пул с очередью задач плохо использует потоки, когда одни задачи порождают множество подзадач и затем ждут их завершения.

ForkJoinPool использует локальные двусторонние очереди и стратегию work-stealing. Свободный worker забирает работу у другого worker, поэтому вычислительная нагрузка распределяется без единой глобальной очереди как обязательной точки конкуренции.

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

Типичный алгоритм сначала передаёт одну подзадачу в пул через fork(), затем выполняет другую напрямую и в конце объединяет результат через join(). Если join() всегда означал обычную блокировку рабочего потока, большое дерево задач могло бы быстро занять все workers ожиданием ещё не запущенных подзадач.

Следствием стал бы thread starvation deadlock: все потоки пула ждут задачи, которые находятся в их очередях, но ни один поток не выполняет их. Дополнительный риск возникает при ожидании внешнего ресурса — например, файла, сети или обычного монитора, — поскольку пул не может автоматически эффективно распорядиться таким ожиданием.

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

Когда worker вызывает ForkJoinTask.join(), пул знает, что ожидается именно fork/join-задача. Вместо пассивного ожидания worker может обработать другие задачи, украсть работу у соседнего worker или содействовать завершению ожидаемой задачи. Конкретный путь зависит от внутреннего состояния пула и графа зависимостей, но принципиально это отличается от безусловного ожидания через обычный Future.get().

Обычно рекомендуется следующая схема: одну часть работы передать через fork(), другую выполнить непосредственно в текущем worker, а затем вызвать join() для первой части. Это уменьшает количество лишних постановок задач в очередь и оставляет текущий поток занятым полезной работой.

import java.util.concurrent.*;

public class Demo {
  static class SumTask extends RecursiveTask<Integer> {
    final int from, to;
    SumTask(int from, int to) { this.from = from; this.to = to; }
    protected Integer compute() {
      if (to - from <= 1) return from;
      int mid = (from + to) / 2;
      SumTask left = new SumTask(from, mid);
      left.fork();
      int right = new SumTask(mid, to).compute();
      return left.join() + right;
    }
  }
  public static void main(String[] args) { System.out.println(new ForkJoinPool().invoke(new SumTask(1, 4))); }
}

Здесь worker не ждёт левую часть сразу после fork(): он вычисляет правую часть напрямую. К моменту join() левая часть часто уже завершена; если нет, механизм fork/join позволяет пулу продолжить полезную работу вместо простоя.

Важно отличать ForkJoinTask.join() от произвольного блокирующего вызова внутри задачи. Ожидание ответа внешнего сервиса, блокировки другого API или Future.get() может занять worker надолго. Для известного неизбежного блокирования применяют ForkJoinPool.ManagedBlocker, чтобы пул мог компенсировать временно недоступный worker, но это не устраняет логические циклы ожидания и не делает внешние блокировки бесплатными.

join() также не спасает от циклических зависимостей: если задача A ждёт B, а B ждёт A, выполнение не завершится. Наконец, fork/join особенно эффективен для CPU-bound работы с достаточно крупными подзадачами; слишком мелкая декомпозиция увеличивает накладные расходы, а сильное разделяемое состояние снижает масштабируемость.

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

В сервисе расчёта отчётов диапазон записей рекурсивно делился на части. Первый вариант создавал подзадачи для обеих половин и затем ожидал обе через join(). При мелких диапазонах количество объектов задач резко росло, а выигрыш от параллелизма исчезал из-за планирования и синхронизации.

Рассматривались два решения. Увеличение параллелизма пула почти не помогало: узким местом оставались накладные расходы и конкуренция за общие структуры. Полный последовательный расчёт был проще, но терял производительность на больших отчётах.

Выбрали адаптивный порог: при малом диапазоне задача обрабатывает данные последовательно, а при большом делится, одну половину запускает через fork(), вторую вычисляет напрямую и затем вызывает join(). Это сохранило загрузку workers, уменьшило число задач и дало предсказуемый выигрыш на крупных отчётах; порог подбирали измерениями, а не произвольным увеличением размера пула.

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

Обязательно ли join() запускать подзадачу, если она была создана, но не вызван fork()?

Нет. Создание ForkJoinTask само по себе не ставит её на выполнение. Подзадачу можно вычислить напрямую вызовом compute() либо передать в пул через fork() или другой механизм запуска. join() ожидает завершения задачи, но не заменяет корректный запуск и не является универсальным способом инициировать произвольную работу.

Почему выполнение одной подзадачи через compute(), а другой через fork() обычно предпочтительнее, чем fork обеих?

Текущий worker сразу занимается одной половиной, а в пул передаётся только дополнительная параллельная работа. При fork обеих половин текущему потоку пришлось бы позже искать работу или ждать, пока обе задачи будут распределены, что увеличивает накладные расходы.

Это эвристика, а не абсолютное правило. Если вычисления неоднородны или одна ветвь значительно тяжелее другой, порядок запуска и выбор ветви для непосредственного вычисления могут влиять на балансировку; решение проверяют профилированием.

Гарантирует ли наличие ForkJoinPool отсутствие взаимных блокировок?

Нет. Пул помогает с ожиданием fork/join-задач, но не устраняет циклы зависимостей и внешние блокировки. Рабочие потоки могут застрять на мониторе, сетевом вводе-выводе или Future, а циклическое ожидание задач остаётся логической ошибкой.

Поэтому в fork/join-задачах стараются использовать независимые вычисления, не блокировать workers внешними ресурсами и явно отделять CPU-bound этапы от операций ожидания. Если блокирование неизбежно, применяют поддерживаемые пулом механизмы вроде ManagedBlocker, но всё равно контролируют число и структуру зависимостей.