Класс ForkJoinTask<V>

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

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

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

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

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

Состояние выполнения задач можно запрашивать с разной степенью подробности: isDone() возвращает true, если задача завершилась любым способом (включая отмену задачи без выполнения); isCompletedNormally() возвращает true, если задача завершилась без отмены и без исключения; 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, предоставляемые этим классом.

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

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

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