Класс ForkJoinTask<V>

public abstract class ForkJoinTask<V>
extends Object
implements Future<V>, Serializable

Абстрактный базовый класс для задач, выполняемых в ForkJoinPool. A ForkJoinTask — это потокоподобный объект, значительно более лёгкий, чем обычный поток. Огромное количество задач и подзадач может быть обработано небольшим количеством фактических потоков в ForkJoinPool, ценой некоторых ограничений в использовании.

«Главная» ForkJoinTask начинает выполнение, когда она явно отправляется в ForkJoinPool, или, если она ещё не задействована в вычислении ForkJoin, начинается в ForkJoinPool.commonPool() через fork(), invoke() или аналогичные методы. После запуска она обычно запускает другие подзадачи. Как следует из названия этого класса, многие программы, использующие ForkJoinTask , используют только методы fork() и join(), или производные, такие как invokeAll. Однако, этот класс также предоставляет ряд других методов, которые могут использоваться в продвинутых приложениях, а также механизмы расширения, которые позволяют поддерживать новые формы обработки fork/join.

A ForkJoinTask — это облегчённая форма Future. Эффективность ForkJoinTask обусловлена набором ограничений (которые только частично могут быть статически проверены), отражающих их основное использование в качестве вычислительных задач, вычисляющих чистые функции или работающих с чисто изолированными объектами. Основными механизмами координации являются fork(), организующий асинхронное выполнение, и join(), который не продолжается, пока результат задачи не будет вычислен. Вычисления должны по возможности избегать synchronized методов или блоков и минимизировать другую блокирующую синхронизацию, кроме объединения других задач или использования синхронизаторов, таких как Phasers, которые объявлены совместимыми с планированием fork/join. Разбиваемые задачи также не должны выполнять блокирующее ввод/вывод и, по возможности, должны обращаться к переменным, которые полностью независимы от переменных, используемых другими работающими задачами. Эти рекомендации слабо соблюдаются, так как не допускаются проверяемые исключения, такие как IOExceptions. Однако вычисления всё ещё могут столкнуться с непроверяемыми исключениями, которые перебрасываются вызывающим сторонам, пытающимся их объединить. Эти исключения могут дополнительно включать RejectedExecutionException, вызванные внутренним исчерпанием ресурсов, например, неудачей выделения внутренних очередей задач. Переброшенные исключения ведут себя так же, как обычные исключения, но, по возможности, содержат стековые следы (отображаемые, например, с помощью ex.printStackTrace()) как потока, который инициировал вычисление, так и потока, на котором фактически произошло исключение; минимально только последнего.

Возможна реализация и использование ForkJoinTasks, которые могут блокироваться, но это требует трёх дополнительных соображений: (1) Завершение каких-либо других задач должно зависеть от задачи, которая блокируется на внешней синхронизации или вводе/выводе. Задачи типа «событие» асинхронного типа, которые никогда не объединяются (например, те, которые наследуют от CountedCompleter), часто относятся к этой категории. (2) Чтобы минимизировать влияние на ресурсы, задачи должны быть небольшими; по идее, выполняя только (возможно) блокирующее действие. (3) Если не используется API ForkJoinPool.ManagedBlocker или количество потенциально заблокированных задач известно меньше уровня параллельности пула ForkJoinPool.getParallelism(), пул не может гарантировать, что будет достаточно потоков для обеспечения прогресса или хорошей производительности.

Основной метод ожидания завершения и извлечения результатов задачи — join(), но есть несколько вариантов: методы Future.get() поддерживают прерывимые и/или ограниченные по времени ожидания завершения и сообщают результаты, используя Future соглашения. Метод invoke() семантически эквивалентен fork(); join(), но всегда пытается начать выполнение в текущем потоке. «Бездействующие» формы этих методов не извлекают результаты или не сообщают об исключениях. Это может быть полезно, когда выполняется набор задач, и вам нужно отложить обработку результатов или исключений до тех пор, пока все не завершатся. Метод invokeAll (доступный в нескольких версиях) выполняет наиболее распространённую форму параллельного вызова: разделение набора задач и объединение их всех.

В самых типичных случаях пара fork-join действует как вызов (fork) и возврат (join) из параллельной рекурсивной функции. Как и в случае с другими видами рекурсивных вызовов, возвраты (объединения) должны выполняться от вложенного к внешнему. Например, a.fork(); b.fork(); b.join(); a.join(); вероятно будет значительно эффективнее, чем объединение a до b.

Состояние выполнения задач может быть запрошено на нескольких уровнях детализации: Future.isDone() равно true, если задача завершена каким-либо образом (включая случай, когда задача была отменена без выполнения); isCompletedNormally() равно true, если задача завершилась без отмены или возникновения исключения; Future.isCancelled() равно true, если задача была отменена (в этом случае getException() возвращает CancellationException); и isCompletedAbnormally() равно true, если задача была отменена или столкнулась с исключением, в этом случае getException() вернёт либо возникшее исключение, либо CancellationException.

Класс ForkJoinTask обычно не наследуется непосредственно. Вместо этого вы наследуете от одного из абстрактных классов, поддерживающих конкретный стиль обработки fork/join, обычно RecursiveAction для большинства вычислений, не возвращающих результаты, RecursiveTask для тех, которые возвращают, и CountedCompleter для тех, в которых завершённые действия вызывают другие действия. Обычно конкретный подкласс ForkJoinTask объявляет поля, составляющие его параметры, установленные в конструкторе, а затем определяет метод compute , который каким-то образом использует методы управления, предоставляемые этим базовым классом.

Метод join() и его варианты подходят только для использования, когда зависимости завершения являются ациклическими; то есть параллельное вычисление может быть описано как ориентированный ациклический граф (DAG). В противном случае, выполнения могут столкнуться с формой тупика, так как задачи циклически ожидают друг друга. Однако, эта платформа поддерживает и другие методы и техники (например, использование Phaser, helpQuiesce() и complete(V)), которые могут быть полезны при создании пользовательских подклассов для задач, которые не имеют статически структурированных DAG. Для поддержки таких применений ForkJoinTask может быть атомарно помечен значением short с помощью setForkJoinTaskTag(short) или compareAndSetForkJoinTaskTag(short, short) и проверен с помощью getForkJoinTaskTag(). Реализация ForkJoinTask не использует эти protected методы или метки ни для каких целей, но они могут быть полезны при создании специализированных подклассов. Например, параллельные обходы графов могут использовать предоставленные методы, чтобы избежать повторного посещения узлов/задач, которые уже были обработаны. (Имена методов для маркировки громоздкие отчасти для поощрения определения методов, которые отражают их шаблоны использования.)

Большинство базовых поддерживающих методов являются final, чтобы предотвратить переопределение реализаций, которые неразрывно связаны с основой планирования лёгких задач. Разработчики, создающие новые базовые стили обработки fork/join, должны по меньшей мере реализовать protected методы exec(), setRawResult(V) и getRawResult(), а также внедрить абстрактный вычислительный метод, который может быть реализован в его подклассах, возможно, опираясь на другие protected методы, предоставляемые этим классом.

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

Этот класс предоставляет adapt методы для Runnable и Callable, которые могут быть полезны при смешении выполнения ForkJoinTasks с другими типами задач. Если все задачи имеют такой вид, рассмотрите использование пула, созданного в режиме asyncMode.

ForkJoinTasks являются Serializable, что позволяет использовать их в расширениях, таких как фреймворки удалённого выполнения. Целесообразно сериализовать задачи только до или после, но не во время выполнения. Сериализация не используется во время самого выполнения.