ForkJoinTask Classe

Définition

[Android.Runtime.Register("java/util/concurrent/ForkJoinTask", DoNotGenerateAcw=true)]
[Java.Interop.JavaTypeParameters(new System.String[] { "V" })]
public abstract class ForkJoinTask : Java.Lang.Object, IDisposable, Java.Interop.IJavaPeerable, Java.IO.ISerializable, Java.Util.Concurrent.IFuture

[<Android.Runtime.Register("java/util/concurrent/ForkJoinTask", DoNotGenerateAcw=true)>]
[<Java.Interop.JavaTypeParameters(new System.String[] { "V" })>]
type ForkJoinTask = class
    inherit Object
    interface ISerializable
    interface IJavaObject
    interface IDisposable
    interface IJavaPeerable
    interface IFuture

Héritage

Object

Object

ForkJoinTask

Dérivé

Java.Util.Concurrent.CountedCompleter

Java.Util.Concurrent.RecursiveAction

Java.Util.Concurrent.RecursiveTask

Attributs

RegisterAttribute JavaTypeParametersAttribute

Implémente

IJavaObject IJavaPeerable ISerializable IFuture IDisposable

Remarques

Classe de base abstraite pour les tâches qui s’exécutent dans un ForkJoinPool. Il ForkJoinTask s’agit d’une entité similaire à un thread qui est beaucoup plus légère qu’un thread normal. Un grand nombre de tâches et de tâches subordonnées peuvent être hébergés par un petit nombre de threads réels dans un ForkJoinPool, au prix de certaines limitations d’utilisation.

Une exécution « principale » ForkJoinTask commence lorsqu’elle est explicitement soumise à un ForkJoinPoolcalcul ForkJoin, ou, si elle n’est pas déjà engagée dans un calcul ForkJoin, commencée dans le ForkJoinPool#commonPool() via #fork, #invokeou des méthodes associées. Une fois démarré, il démarre généralement d’autres tâches secondaires. Comme indiqué par le nom de cette classe, de nombreux programmes utilisant ForkJoinTask uniquement des méthodes #fork et #join, ou des dérivés tels que #invokeAll(ForkJoinTask...) invokeAll. Toutefois, cette classe fournit également un certain nombre d’autres méthodes qui peuvent entrer en jeu dans les utilisations avancées, ainsi que des mécanismes d’extension qui permettent la prise en charge de nouvelles formes de fork/jointure de traitement.

A ForkJoinTask est une forme légère de Future. L’efficacité des ForkJoinTasks provient d’un ensemble de restrictions (qui ne sont que partiellement appliquées de manière statique) reflétant leur utilisation principale en tant que tâches de calculant des fonctions pures ou fonctionnant sur des objets purement isolés. Les mécanismes de coordination principaux sont #fork, qui organise l’exécution asynchrone et #join, qui ne se poursuit pas tant que le résultat de la tâche n’a pas été calculé. Les calculs doivent idéalement éviter synchronized les méthodes ou les blocs, et doivent réduire au minimum d’autres synchronisations bloquantes en dehors de joindre d’autres tâches ou utiliser des synchronisateurs tels que des phases publiés pour coopérer avec la planification du fork/jointure. Les tâches subdividables ne doivent pas non plus effectuer d’E/S bloquantes et doivent idéalement accéder aux variables qui sont complètement indépendantes de celles accessibles par d’autres tâches en cours d’exécution. Ces instructions sont appliquées de manière libre en ne autorisant pas les exceptions vérifiées telles qu’à IOExceptions lever. Toutefois, les calculs peuvent toujours rencontrer des exceptions non vérifiées, qui sont réexpédées aux appelants qui tentent de les joindre. Ces exceptions peuvent également inclure des RejectedExecutionException conséquences liées à l’épuisement des ressources internes, telles que l’échec de l’allocation de files d’attente de tâches internes. Les exceptions rethrown se comportent de la même façon que les exceptions régulières, mais, dans la mesure du possible, contiennent des traces de pile (comme affichées par exemple à l’aide ex.printStackTrace()) du thread qui a lancé le calcul ainsi que le thread rencontre réellement l’exception ; ce dernier est minimement.

Il est possible de définir et d’utiliser ForkJoinTasks qui peuvent bloquer, mais cela nécessite trois considérations supplémentaires : (1) L’achèvement de quelques <tâches em>autres</em> doit dépendre d’une tâche qui bloque la synchronisation externe ou les E/S. Les tâches asynchrones de style événement qui ne sont jamais jointes (par exemple, ces sous-classes CountedCompleter) tombent souvent dans cette catégorie. (2) Pour réduire l’impact des ressources, les tâches doivent être petites ; dans l’idéal, il n’effectue que l’action de blocage (éventuellement). (3) Sauf si l’API est utilisée ou si le ForkJoinPool.ManagedBlocker nombre de tâches éventuellement bloquées est inférieur au niveau du ForkJoinPool#getParallelism pool, le pool ne peut pas garantir que suffisamment de threads seront disponibles pour garantir la progression ou de bonnes performances.

La méthode principale d’attente et d’extraction des résultats d’une tâche est #join, mais il existe plusieurs variantes : les Future#get méthodes prennent en charge les attentes interrompues et/ou chronométrées pour l’achèvement et les résultats de rapport à l’aide Future de conventions. La méthode #invoke est sémantiquement équivalente à fork(); join() mais tente toujours de commencer l’exécution dans le thread actuel. Les formes «< em>quiet</em> » de ces méthodes n’extraient pas les résultats ni les exceptions de rapport. Cela peut s’avérer utile lorsqu’un ensemble de tâches est en cours d’exécution et que vous devez retarder le traitement des résultats ou des exceptions jusqu’à ce que toutes les tâches soient terminées. La méthode invokeAll (disponible dans plusieurs versions) effectue la forme la plus courante d’appel parallèle : la duplication d’un ensemble de tâches et leur jointure.

Dans les utilisations les plus courantes, une paire fork-join agit comme un appel (fork) et retourne (jointure) à partir d’une fonction récursive parallèle. Comme c’est le cas avec d’autres formes d’appels récursifs, les retours (jointures) doivent être effectués en premier. Par exemple, a.fork(); b.fork(); b.join(); a.join(); il est probable qu’il soit beaucoup plus efficace que de a joindre avant b.

L’état d’exécution des tâches peut être interrogé à plusieurs niveaux de détail : #isDone est vrai si une tâche s’est terminée de quelque manière (y compris le cas où une tâche a été annulée sans exécution) ; #isCompletedNormally est vraie si une tâche s’est terminée sans annulation ou rencontre une exception ; #isCancelled est vraie si la tâche a été annulée (auquel cas #getException retourne une CancellationException) ; et #isCompletedAbnormally est vraie si une tâche a été annulée ou a rencontré une exception, dans ce cas #getException , retourne l’exception rencontrée ou CancellationException.

La classe ForkJoinTask n’est généralement pas directement sous-classée. Au lieu de cela, vous sous-classez l’une des classes abstraites qui prennent en charge un style particulier de traitement de fork/jointure, généralement RecursiveAction pour la plupart des calculs qui ne retournent pas de résultats, RecursiveTask pour ceux qui le font et CountedCompleter pour ceux dans lesquels les actions terminées déclenchent d’autres actions. Normalement, une sous-classe ForkJoinTask concrète déclare des champs comprenant ses paramètres, établis dans un constructeur, puis définit une compute méthode qui utilise en quelque sorte les méthodes de contrôle fournies par cette classe de base.

La méthode #join et ses variantes sont appropriées pour être utilisées uniquement lorsque les dépendances d’achèvement sont acycliques ; autrement dit, le calcul parallèle peut être décrit comme un graphe acyclique dirigé (DAG). Sinon, les exécutions peuvent rencontrer une forme d’interblocage, car les tâches attendent cycliquement les unes des autres. Toutefois, cette infrastructure prend en charge d’autres méthodes et techniques (par exemple l’utilisation de Phaser, #helpQuiesceet #complete) qui peuvent être utilisées dans la construction de sous-classes personnalisées pour les problèmes qui ne sont pas structurés statiquement en tant que DAGs. Pour prendre en charge de telles utilisations, un ForkJoinTask peut être marqué atomiquement em tagged</em> avec une short valeur utilisant #setForkJoinTaskTag ou #compareAndSetForkJoinTaskTag vérifié à l’aide #getForkJoinTaskTag.>< L’implémentation forkJoinTask n’utilise pas ces protected méthodes ou balises à des fins quelconques, mais elles peuvent être utilisées dans la construction de sous-classes spécialisées. Par exemple, les traversées de graphiques parallèles peuvent utiliser les méthodes fournies pour éviter de revoir les nœuds/tâches qui ont déjà été traités. (Les noms de méthodes pour l’étiquetage sont volumineux en partie pour encourager la définition des méthodes qui reflètent leurs modèles d’utilisation.)

La plupart des méthodes de prise en charge de base sont final, pour empêcher la substitution d’implémentations liées intrinsèquement à l’infrastructure de planification des tâches légères sous-jacente. Les développeurs qui créent de nouveaux styles de base de traitement de fork/jointure doivent implémenter protected minimalement des méthodes #exec, #setRawResultet #getRawResult, tout en introduisant également une méthode de calcul abstraite qui peut être implémentée dans ses sous-classes, éventuellement en s’appuyant sur d’autres protected méthodes fournies par cette classe.

ForkJoinTasks doit effectuer des quantités relativement petites de calcul. Les tâches volumineuses doivent être divisées en sous-tâches plus petites, généralement par décomposition récursive. En règle générale, une tâche doit effectuer plus de 100 et moins de 1 000 étapes de calcul de base et éviter une boucle indéfinie. Si les tâches sont trop volumineuses, le parallélisme ne peut pas améliorer le débit. Si elle est trop petite, la surcharge de maintenance de la mémoire et des tâches internes peut surcharger le traitement.

Cette classe fournit des adapt méthodes pour Runnable et Callable, qui peuvent être utilisées lors de la combinaison de l’exécution avec ForkJoinTasks d’autres types de tâches. Lorsque toutes les tâches sont de ce formulaire, envisagez d’utiliser un pool construit dans <em>asyncMode</em>.

ForkJoinTasks sont Serializable, ce qui leur permet d’être utilisés dans des extensions telles que des frameworks d’exécution à distance. Il est judicieux de sérialiser les tâches uniquement avant ou après, mais pas pendant l’exécution. La sérialisation n’est pas basée sur pendant l’exécution elle-même.

Ajouté dans la version 1.7.

Documentation Java pour java.util.concurrent.ForkJoinTask.

Les parties de cette page sont des modifications basées sur le travail créé et partagé par le projet Android Open Source et utilisés en fonction des termes décrits dans la licence d’attribution Creative Commons 2.5.

Constructeurs

Propriétés

Méthodes

Implémentations d’interfaces explicites

Méthodes d’extension

S’applique à