Класс ForkJoinTask<V>

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

Задача ForkJoinTask является лёгкой формой Future. Эффективность ForkJoinTask обусловлена набором ограничений (которые только частично статически проверяются), отражающих их основное использование как вычислительных задач, вычисляющих чистые функции или работающих с чисто изолированными объектами. Основными механизмами координации являются fork(), который организует асинхронное выполнение, и join(), который не продолжает выполнение, пока результат задачи не будет вычислен. Вычисления в идеале должны избегать методов или блоков synchronized, и должны минимизировать другую блокирующую синхронизацию, кроме объединения других задач или использования синхронизаторов, таких как фазы, которые рекламируются для сотрудничества с планированием 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) из параллельной рекурсивной функции. Как и в случае с другими формами рекурсивных вызовов, возвраты (join) должны выполняться от внутреннего к внешнему. Например, a.fork(); b.fork(); b.join(); a.join(); вероятно будет значительно эффективнее, чем объединение a до b.

Статус выполнения задач может быть запрошен на нескольких уровнях детализации: isDone() — true, если задача завершилась каким-либо образом (включая случай, когда задача была отменена без выполнения); isCompletedNormally() — true, если задача завершилась без отмены или возникновения исключения; isCancelled() — true, если задача была отменена (в этом случае getException(int) возвращает CancellationException); и isCompletedAbnormally() — true, если задача была отменена или столкнулась с исключением, в этом случае getException(int) вернёт либо возникшее исключение, либо 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, что позволяет использовать их в расширениях, таких как фреймворки удалённого выполнения. Целесообразно сериализовать задачи только до или после, но не во время выполнения. Сериализация не используется во время выполнения.