ThreadPoolExecutor Classe

Définition

[Android.Runtime.Register("java/util/concurrent/ThreadPoolExecutor", DoNotGenerateAcw=true)]
public class ThreadPoolExecutor : Java.Util.Concurrent.AbstractExecutorService

[<Android.Runtime.Register("java/util/concurrent/ThreadPoolExecutor", DoNotGenerateAcw=true)>]
type ThreadPoolExecutor = class
    inherit AbstractExecutorService

Héritage

Object

Object

AbstractExecutorService

ThreadPoolExecutor

Dérivé

Java.Util.Concurrent.ScheduledThreadPoolExecutor

Attributs

RegisterAttribute

Remarques

Qui ExecutorService exécute chaque tâche envoyée à l’aide de l’un des threads mis en pool, normalement configuré à l’aide Executors de méthodes de fabrique.

Les pools de threads résolvent deux problèmes différents : ils fournissent généralement des performances améliorées lors de l’exécution d’un grand nombre de tâches asynchrones, en raison d’une surcharge d’appel par tâche réduite et fournissent un moyen de délimitation et de gestion des ressources, y compris les threads, consommés lors de l’exécution d’une collection de tâches. Chacun ThreadPoolExecutor gère également certaines statistiques de base, telles que le nombre de tâches terminées.

Pour être utile dans un large éventail de contextes, cette classe fournit de nombreux paramètres réglables et crochets d’extensibilité. Toutefois, les programmeurs sont invités à utiliser les méthodes Executors#newCachedThreadPool de fabrique les plus pratiques Executors (pool de threads non liés, avec récupération automatique des threads), Executors#newFixedThreadPool (pool de threads de taille fixe) et Executors#newSingleThreadExecutor (thread d’arrière-plan unique), qui préconfigurent les scénarios d’utilisation les plus courants. Sinon, utilisez le guide suivant lors de la configuration et du réglage manuels de cette classe :

<dl>

<dt>Core et tailles de pool maximales</dt>

<dd>A ThreadPoolExecutor ajuste automatiquement la taille du pool (voir #getPoolSize) en fonction des limites définies par corePoolSize (voir #getCorePoolSize) et maximumPoolSize (voir #getMaximumPoolSize).

Lorsqu’une nouvelle tâche est envoyée dans la méthode #execute(Runnable), si moins de threads corePoolSize sont en cours d’exécution, un nouveau thread est créé pour gérer la requête, même si d’autres threads de travail sont inactifs. Sinon, si moins de threadsPoolSize sont en cours d’exécution, un nouveau thread est créé pour gérer la requête uniquement si la file d’attente est pleine. En définissant corePoolSize et maximumPoolSize identiques, vous créez un pool de threads de taille fixe. En définissant maximumPoolSize sur une valeur essentiellement illimitée telle que Integer.MAX_VALUE, vous autorisez le pool à prendre en charge un nombre arbitraire de tâches simultanées. La plupart du temps, les tailles de noyau et de pool maximale sont définies uniquement lors de la construction, mais elles peuvent également être modifiées dynamiquement à l’aide #setCorePoolSize et #setMaximumPoolSize. </Dd>

<dt construction</dt>à la demande>

<dd>Par défaut, même les threads principaux sont initialement créés et démarrés uniquement lorsque de nouvelles tâches arrivent, mais cela peut être substitué dynamiquement à l’aide de la méthode #prestartCoreThread ou #prestartAllCoreThreads. Vous souhaitez probablement prédémarrer les threads si vous construisez le pool avec une file d’attente non vide. </Dd>

<dt>Création de threads</dt>

<dd>New threads sont créés à l’aide d’un ThreadFactory. Si ce n’est pas le cas, un Executors#defaultThreadFactory thread est utilisé, ce qui crée des threads dans le même ThreadGroup état et avec la même priorité et le même NORM_PRIORITY état non démon. En fournissant un autre ThreadFactory, vous pouvez modifier le nom du thread, le groupe de threads, la priorité, l’état du démon, etc. Si un ThreadFactory thread ne parvient pas à créer un thread lorsqu’il est demandé en retournant null, newThreadl’exécuteur continue, mais peut ne pas être en mesure d’exécuter des tâches. Les threads doivent posséder la propriété « modifyThread ». RuntimePermission Si les threads de travail ou d’autres threads utilisant le pool ne possèdent pas cette autorisation, le service peut être détérioré : les modifications de configuration peuvent ne pas prendre effet en temps voulu et un pool d’arrêt peut rester dans un état dans lequel l’arrêt est possible, mais pas terminé.</Dd>

<>temps de conservation</dt>

<dd>Si le pool a actuellement plus de threads corePoolSize, des threads excédentaires sont arrêtés s’ils ont été inactifs pendant plus que keepAliveTime (voir #getKeepAliveTime(TimeUnit)). Cela permet de réduire la consommation des ressources lorsque le pool n’est pas utilisé activement. Si le pool devient plus actif plus tard, de nouveaux threads seront construits. Ce paramètre peut également être modifié dynamiquement à l’aide de la méthode #setKeepAliveTime(long, TimeUnit). L’utilisation d’une valeur permettant de Long.MAX_VALUETimeUnit#NANOSECONDS désactiver efficacement les threads inactifs ne cesse de se terminer avant d’arrêter. Par défaut, la stratégie keep-alive s’applique uniquement lorsqu’il existe plus de threads corePoolSize, mais la méthode peut être utilisée pour appliquer cette stratégie #allowCoreThreadTimeOut(boolean) de délai d’attente aux threads principaux, tant que la valeur keepAliveTime n’est pas zéro. </Dd>

<dt>Queuing</dt>

<dd>Tout BlockingQueue peut être utilisé pour transférer et contenir les tâches soumises. L’utilisation de cette file d’attente interagit avec le dimensionnement du pool :

<ul>

<li>Si moins de threads corePoolSize sont en cours d’exécution, l’exécuteur préfère toujours ajouter un nouveau thread plutôt que de mettre en file d’attente.

<li>If corePoolSize ou plusieurs threads sont en cours d’exécution, l’exécuteur préfère toujours mettre en file d’attente une requête plutôt que d’ajouter un nouveau thread.

<li>Si une requête ne peut pas être mise en file d’attente, un nouveau thread est créé, sauf si cela dépasse maximumPoolSize, auquel cas, la tâche est rejetée.

</ul>

Il existe trois stratégies générales pour la mise en file d’attente : <ol>

<li><em> Direct handoffs.</em> Un bon choix par défaut pour une file d’attente de travail est une SynchronousQueue tâche qui remet les tâches aux threads sans les conserver. Ici, une tentative de file d’attente d’une tâche échoue si aucun thread n’est immédiatement disponible pour l’exécuter, de sorte qu’un nouveau thread sera construit. Cette stratégie évite les verrouillages lors de la gestion des ensembles de requêtes susceptibles d’avoir des dépendances internes. Les documents directs nécessitent généralement un maximum depoolSizes sans limite pour éviter le rejet de nouvelles tâches soumises. Cela admet à son tour la possibilité de croissance des threads non liés lorsque les commandes continuent d’arriver en moyenne plus rapidement qu’elles ne peuvent être traitées.

<files d’attente non liées li><em> .</em> L’utilisation d’une file d’attente sans limite (par exemple, sans LinkedBlockingQueue capacité prédéfinie) entraîne l’attente de nouvelles tâches dans la file d’attente lorsque tous les threads corePoolSize sont occupés. Ainsi, pas plus que les threads corePoolSize ne seront jamais créés. (Et la valeur du maximumPoolSize n’a donc aucun effet.) Cela peut être approprié lorsque chaque tâche est complètement indépendante des autres, de sorte que les tâches ne peuvent pas affecter l’exécution des autres ; par exemple, dans un serveur de pages web. Bien que ce style de mise en file d’attente puisse être utile pour lissage des rafales temporaires de requêtes, il admet la possibilité d’une croissance de file d’attente de travail sans limite lorsque les commandes continuent d’arriver en moyenne plus rapidement qu’elles ne peuvent être traitées.

<files d’attente limitées li><em>.</em> Une file d’attente limitée (par exemple, un ArrayBlockingQueue) permet d’empêcher l’épuisement des ressources lorsqu’elle est utilisée avec des valeurs maximales limitées, mais peut être plus difficile à régler et contrôler. Les tailles de file d’attente et les tailles de pool maximales peuvent être échangées entre elles : l’utilisation de files d’attente volumineuses et de petits pools réduit l’utilisation du processeur, les ressources du système d’exploitation et la surcharge de basculement de contexte, mais peut entraîner un débit artificiellement faible. Si les tâches bloquent fréquemment (par exemple si elles sont liées aux E/S), un système peut être en mesure de planifier du temps pour plus de threads que vous ne l’autorisez dans le cas contraire. L’utilisation de petites files d’attente nécessite généralement des tailles de pool plus grandes, ce qui maintient les processeurs plus busé, mais peut rencontrer une surcharge de planification inacceptable, ce qui réduit également le débit.

</ol>

</Dd>

<tâches rejetées</dt>>

<Dd>Nouvelles tâches soumises dans la méthode #execute(Runnable) sont <>rejetées</em> lorsque l’exécuteur a été arrêté, et également lorsque l’exécuteur utilise des limites finies pour les threads maximum et la capacité de file d’attente de travail, et est saturé. Dans les deux cas, la execute méthode appelle la RejectedExecutionHandler#rejectedExecution(Runnable, ThreadPoolExecutor) méthode de son RejectedExecutionHandler. Quatre stratégies de gestionnaire prédéfinies sont fournies :

<ol>

<li>Dans la valeur par défaut ThreadPoolExecutor.AbortPolicy, le gestionnaire lève un runtime RejectedExecutionException lors du rejet.

<li>In ThreadPoolExecutor.CallerRunsPolicy, le thread qui s’appelle execute lui-même exécute la tâche. Cela fournit un mécanisme de contrôle de commentaires simple qui ralentit le taux d’envoi de nouvelles tâches.

<li>In ThreadPoolExecutor.DiscardPolicy, une tâche qui ne peut pas être exécutée est simplement supprimée. Cette stratégie est conçue uniquement pour les rares cas où l’achèvement de la tâche n’est jamais utilisé.

<li>In ThreadPoolExecutor.DiscardOldestPolicy, si l’exécuteur n’est pas arrêté, la tâche à la tête de la file d’attente de travail est supprimée, puis l’exécution est retentée (qui peut échouer à nouveau, ce qui entraîne la répétition de cette opération.) Cette stratégie est rarement acceptable. Dans presque tous les cas, vous devez également annuler la tâche pour provoquer une exception dans n’importe quel composant en attente de sa fin et/ou consigner l’échec, comme illustré dans la ThreadPoolExecutor.DiscardOldestPolicy documentation.

</ol>

Il est possible de définir et d’utiliser d’autres types de RejectedExecutionHandler classes. Cela nécessite des soins en particulier lorsque les stratégies sont conçues pour fonctionner uniquement sous une capacité particulière ou des stratégies de mise en file d’attente. </Dd>

<méthodes< dt>Hook/dt>

<dd>Cette classe fournit des protected méthodes substituables #beforeExecute(Thread, Runnable)#afterExecute(Runnable, Throwable) qui sont appelées avant et après l’exécution de chaque tâche. Ils peuvent être utilisés pour manipuler l’environnement d’exécution ; par exemple, réinitialiser ThreadLocals, collecter des statistiques ou ajouter des entrées de journal. En outre, la méthode #terminated peut être substituée pour effectuer tout traitement spécial qui doit être effectué une fois que l’exécuteur a entièrement terminé.

Si les méthodes hook, callback ou BlockingQueue lèvent des exceptions, les threads de travail internes peuvent à leur tour échouer, arrêter brusquement et éventuellement être remplacés.</Dd>

<maintenance< de file dt dt>/dt>

<La méthode #getQueue() dd>autorise l’accès à la file d’attente de travail à des fins de surveillance et de débogage. L’utilisation de cette méthode à d’autres fins est fortement déconseillée. Deux méthodes fournies et #remove(Runnable)#purge sont disponibles pour faciliter la récupération du stockage quand un grand nombre de tâches en file d’attente sont annulées.</Dd>

<dt>Reclamation</dt>

<Dd>Un pool qui n’est plus référencé dans un programme <EM>AND</em> n’a pas de threads restants peut être récupéré (garbage collected) sans être explicitement arrêté. Vous pouvez configurer un pool pour permettre à tous les threads inutilisés de mourir en définissant des heures de conservation appropriées, en utilisant une limite inférieure de threads de cœurs zéro et/ou paramètre #allowCoreThreadTimeOut(boolean). </Dd>

</Dl>

<b>Exemple d’extension.</b> La plupart des extensions de cette classe remplacent une ou plusieurs des méthodes de hook protégées. Par exemple, voici une sous-classe qui ajoute une fonctionnalité de pause/reprise simple :

{@code
            class PausableThreadPoolExecutor extends ThreadPoolExecutor {
              private boolean isPaused;
              private ReentrantLock pauseLock = new ReentrantLock();
              private Condition unpaused = pauseLock.newCondition();

              public PausableThreadPoolExecutor(...) { super(...); }

              protected void beforeExecute(Thread t, Runnable r) {
                super.beforeExecute(t, r);
                pauseLock.lock();
                try {
                  while (isPaused) unpaused.await();
                } catch (InterruptedException ie) {
                  t.interrupt();
                } finally {
                  pauseLock.unlock();
                }
              }

              public void pause() {
                pauseLock.lock();
                try {
                  isPaused = true;
                } finally {
                  pauseLock.unlock();
                }
              }

              public void resume() {
                pauseLock.lock();
                try {
                  isPaused = false;
                  unpaused.signalAll();
                } finally {
                  pauseLock.unlock();
                }
              }
            }}

Ajouté à la version 1.5.

Documentation Java pour java.util.concurrent.ThreadPoolExecutor.

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 à