Класс ForkJoinTask<V>

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

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

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

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

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