ThreadPoolExecutor Klasse

Definition

[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

Vererbung

Object

Object

AbstractExecutorService

ThreadPoolExecutor

Abgeleitet

Java.Util.Concurrent.ScheduledThreadPoolExecutor

Attribute

RegisterAttribute

Hinweise

Ein ExecutorService Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit Executors Factorymethoden konfiguriert.

Threadpools lösen zwei unterschiedliche Probleme aus: Sie bieten in der Regel eine verbesserte Leistung beim Ausführen einer großen Anzahl asynchroner Aufgaben, aufgrund eines reduzierten Vorgangsaufrufaufwands, und sie bieten eine Möglichkeit zum Binden und Verwalten der Ressourcen, einschließlich Threads, die beim Ausführen einer Sammlung von Aufgaben verbraucht werden. Jede ThreadPoolExecutor verwaltet auch einige grundlegende Statistiken, z. B. die Anzahl der abgeschlossenen Aufgaben.

Um in einem breiten Spektrum von Kontexten nützlich zu sein, bietet diese Klasse viele anpassbare Parameter und Erweiterbarkeitshaken. Programmierer werden jedoch aufgefordert, die bequemeren Executors Factorymethoden Executors#newCachedThreadPool (ungebundene Threadpools, mit automatischer Thread reclamation), Executors#newFixedThreadPool (Threadpool mit fester Größe) und Executors#newSingleThreadExecutor (einzelner Hintergrundthread) zu verwenden, die Einstellungen für die am häufigsten verwendeten Verwendungsszenarien vorkonfigurieren. Verwenden Sie andernfalls den folgenden Leitfaden, wenn Sie diese Klasse manuell konfigurieren und optimieren:

<dl>

<dt>Core und maximale Poolgrößen</dt>

<dd>A ThreadPoolExecutor passt die Poolgröße (siehe #getPoolSize) automatisch entsprechend den Grenzen an, die von corePoolSize (siehe #getCorePoolSize) und maximumPoolSize festgelegt werden (siehe #getMaximumPoolSize).

Wenn eine neue Aufgabe in der Methode #execute(Runnable)übermittelt wird, wenn weniger als corePoolSize-Threads ausgeführt werden, wird ein neuer Thread erstellt, um die Anforderung zu verarbeiten, auch wenn andere Arbeitsthreads im Leerlauf sind. Andernfalls, wenn weniger als maximumPoolSize-Threads ausgeführt werden, wird ein neuer Thread erstellt, um die Anforderung nur zu verarbeiten, wenn die Warteschlange voll ist. Indem Sie "corePoolSize" und "maximumPoolSize" festlegen, erstellen Sie einen Threadpool mit fester Größe. Indem Sie "maximumPoolSize" auf einen im Wesentlichen ungebundenen Wert festlegen, z Integer.MAX_VALUE. B. erlauben Sie dem Pool, eine beliebige Anzahl gleichzeitiger Vorgänge aufzunehmen. In der Regel werden kerne und maximale Poolgrößen nur bei der Konstruktion festgelegt, aber sie können auch dynamisch verwendet #setCorePoolSize und #setMaximumPoolSizegeändert werden. </Dd>

<dt>On-Demand-Bau</dt>

<dd>Standardmäßig werden sogar Kernthreads anfangs erstellt und nur gestartet, wenn neue Aufgaben eintreffen, dies kann jedoch dynamisch mithilfe der Methode #prestartCoreThread oder #prestartAllCoreThreadsder Methode überschrieben werden. Wahrscheinlich möchten Sie Threads vorab starten, wenn Sie den Pool mit einer nicht leeren Warteschlange erstellen. </Dd>

<dt>Erstellen neuer Threads</dt>

<dd>New threads are created using a ThreadFactory. Wenn nicht anders angegeben, wird eine Executors#defaultThreadFactory verwendet, die Threads erstellt, die alle in demselben ThreadGroup und mit derselben NORM_PRIORITY Priorität und nicht-Daemon-Status vorhanden sind. Durch Bereitstellen einer anderen ThreadFactory können Sie den Namen, die Threadgruppe, die Priorität, den Daemonstatus usw. ändern. Wenn beim Zurückgeben von NULL newThreadein ThreadFactory Thread nicht erstellt werden kann, wird der Executor fortgesetzt, kann aber möglicherweise keine Aufgaben ausführen. Threads sollten über das "modifyThread" RuntimePermissionverfügen. Wenn Arbeitsthreads oder andere Threads, die den Pool verwenden, nicht über diese Berechtigung verfügen, kann der Dienst beeinträchtigt werden: Konfigurationsänderungen werden möglicherweise nicht rechtzeitig wirksam, und ein Herunterfahrenspool verbleibt möglicherweise in einem Zustand, in dem die Beendigung möglich, aber nicht abgeschlossen ist.</Dd>

<dt>Keep-Alive-Zeiten</dt>

<dd>Wenn der Pool zurzeit mehr als corePoolSize-Threads aufweist, werden überzählige Threads beendet, wenn sie für mehr als die keepAliveTime im Leerlauf waren (siehe #getKeepAliveTime(TimeUnit)). Dies ermöglicht eine Verringerung des Ressourcenverbrauchs, wenn der Pool nicht aktiv verwendet wird. Wenn der Pool später aktiver wird, werden neue Threads erstellt. Dieser Parameter kann auch dynamisch mithilfe der Methode #setKeepAliveTime(long, TimeUnit)geändert werden. Die Verwendung eines Werts von Long.MAX_VALUETimeUnit#NANOSECONDS effektiven Deaktivieren von Leerlaufthreads wird vor dem Herunterfahren deaktiviert. Standardmäßig gilt die Keep-Alive-Richtlinie nur, wenn mehr als corePoolSize-Threads vorhanden sind. Die Methode #allowCoreThreadTimeOut(boolean) kann jedoch verwendet werden, um diese Timeoutrichtlinie auch auf Kernthreads anzuwenden, solange der keepAliveTime-Wert ungleich Null ist. </Dd>

<dt>Queuing</dt>

<dd>Any BlockingQueue may be used to transfer and hold submitted tasks. Die Verwendung dieser Warteschlange interagiert mit der Größe des Pools:

<ul>

<li>Wenn weniger als corePoolSize-Threads ausgeführt werden, bevorzugt der Executor immer das Hinzufügen eines neuen Threads anstelle der Warteschlange.

<li>Wenn corePoolSize oder mehr Threads ausgeführt werden, bevorzugt der Executor immer die Warteschlange einer Anforderung, anstatt einen neuen Thread hinzuzufügen.

<li>Wenn eine Anforderung nicht in die Warteschlange gestellt werden kann, wird ein neuer Thread erstellt, es sei denn, dies würde maximumPoolSize überschreiten, in diesem Fall wird die Aufgabe abgelehnt.

</ul>

Es gibt drei allgemeine Strategien für die Warteschlangen: <ol>

<li><em> Direct Handoffs.</em> Eine gute Standardauswahl für eine Arbeitswarteschlange ist eine SynchronousQueue , die Aufgaben an Threads aushändigt, ohne sie andernfalls zu halten. Hier schlägt ein Versuch, eine Aufgabe in die Warteschlange zu stellen, fehl, wenn keine Threads sofort zur Ausführung verfügbar sind, sodass ein neuer Thread erstellt wird. Diese Richtlinie vermeidet Sperrungen beim Behandeln von Anforderungen, die möglicherweise interne Abhängigkeiten aufweisen. Direkte Übergaben erfordern in der Regel ungebundene MaximumPoolSizes, um die Ablehnung neuer übermittelter Vorgänge zu vermeiden. Dies wiederum gibt die Möglichkeit eines ungebundenen Threadwachstums zu, wenn Befehle weiterhin im Durchschnitt schneller ankommen, als sie verarbeitet werden können.

<li><em> Ungebundene Warteschlangen.</em> Die Verwendung einer ungebundenen Warteschlange (z. B. eine LinkedBlockingQueue ohne vordefinierte Kapazität) bewirkt, dass neue Aufgaben in der Warteschlange warten, wenn alle CorePoolSize-Threads ausgelastet sind. Daher werden nie mehr als corePoolSize-Threads erstellt. (Und der Wert des maximumPoolSize hat daher keine Auswirkung.) Dies kann angemessen sein, wenn jede Aufgabe vollständig unabhängig von anderen ist, sodass Vorgänge sich nicht auf die Ausführung der anderen auswirken können. z. B. auf einem Webseitenserver. Während diese Art der Warteschlange beim Glätten vorübergehender Anforderungen nützlich sein kann, lässt sie die Möglichkeit zu, dass ungebundene Arbeitswarteschlangen wachsen, wenn Befehle weiterhin im Durchschnitt schneller ankommen, als sie verarbeitet werden können.

<li><em>bounded queues.</em> Eine gebundene Warteschlange (z. B. eine ArrayBlockingQueue) verhindert die Ressourcenausschöpfung bei Verwendung mit endlichen maximumPoolSizes, kann aber schwieriger zu optimieren und zu steuern sein. Warteschlangengrößen und maximale Poolgrößen können voneinander abgetauscht werden: Die Verwendung großer Warteschlangen und kleiner Pools minimiert cpu-Auslastung, Betriebssystemressourcen und Kontextwechsel-Overhead, kann jedoch zu einem künstlich niedrigen Durchsatz führen. Wenn Vorgänge häufig blockieren (z. B. wenn sie E/A gebunden sind), kann ein System möglicherweise Zeit für mehr Threads planen, als Sie andernfalls zulassen. Die Verwendung kleiner Warteschlangen erfordert in der Regel größere Poolgrößen, wodurch CPUs busierer bleiben, aber möglicherweise ein inakzeptabler Planungsaufwand auftritt, was auch den Durchsatz verringert.

</ol>

</Dd>

<dt>Abgelehnte Vorgänge</dt>

<dd>New tasks submitted in method #execute(Runnable) will be <rejected></em> when the Executor has been shut down, and also when the Executor uses finite bounds for both maximum threads and work queue capacity, and is saturated. In beiden Fällen ruft die execute Methode die RejectedExecutionHandler#rejectedExecution(Runnable, ThreadPoolExecutor) Methode auf RejectedExecutionHandler. Es werden vier vordefinierte Handlerrichtlinien bereitgestellt:

<ol>

<li>Im Standard ThreadPoolExecutor.AbortPolicylöst der Handler eine Laufzeit RejectedExecutionException nach Ablehnung aus.

<li>In ThreadPoolExecutor.CallerRunsPolicy, der Thread, der sich selbst aufruft execute , führt die Aufgabe aus. Dies bietet einen einfachen Feedbacksteuerungsmechanismus, mit dem die Rate verlangsamt wird, mit der neue Vorgänge übermittelt werden.

<li>In ThreadPoolExecutor.DiscardPolicy, eine Aufgabe, die nicht ausgeführt werden kann, wird einfach gelöscht. Diese Richtlinie ist nur für die seltenen Fälle vorgesehen, in denen der Vorgangsabschluss niemals verwendet wird.

<li>In ThreadPoolExecutor.DiscardOldestPolicy, wenn der Executor nicht heruntergefahren wird, wird die Aufgabe an der Spitze der Arbeitswarteschlange verworfen, und die Ausführung wird erneut versucht (was erneut fehlschlagen kann, was dazu führt, dass dies wiederholt wird.) Diese Richtlinie ist selten akzeptabel. In fast allen Fällen sollten Sie die Aufgabe auch abbrechen, um eine Ausnahme in jeder Komponente zu verursachen, die auf den Abschluss wartet, und/oder protokollieren Sie den Fehler, wie in ThreadPoolExecutor.DiscardOldestPolicy der Dokumentation dargestellt.

</ol>

Es ist möglich, andere Arten von RejectedExecutionHandler Klassen zu definieren und zu verwenden. Dies erfordert eine gewisse Sorgfalt, insbesondere wenn Richtlinien nur unter bestimmten Kapazitäts- oder Warteschlangenrichtlinien funktionieren sollen. </Dd>

<dt>Hook-Methoden</dt>

<dd>This class provides protected overridable #beforeExecute(Thread, Runnable) and #afterExecute(Runnable, Throwable) methods that are called before and after execution of each task. Diese können verwendet werden, um die Ausführungsumgebung zu bearbeiten; Beispiel: erneutes Initialisieren von ThreadLocals, Sammeln von Statistiken oder Hinzufügen von Protokolleinträgen. Darüber hinaus kann die Methode #terminated überschrieben werden, um eine spezielle Verarbeitung durchzuführen, die ausgeführt werden muss, nachdem der Executor vollständig beendet wurde.

Wenn Hook-, Rückruf- oder BlockingQueue-Methoden Ausnahmen auslösen, können interne Arbeitsthreads wiederum fehlschlagen, abrupt beendet und möglicherweise ersetzt werden.</Dd>

<dt>Warteschlangenwartung</dt>

<dd-Methode>#getQueue() ermöglicht den Zugriff auf die Arbeitswarteschlange für Zwecke der Überwachung und des Debuggens. Die Verwendung dieser Methode für andere Zwecke wird dringend abgeraten. Zwei bereitgestellte Methoden und #purge stehen zur Verfügung, #remove(Runnable) um die Speicherbeschriftung zu unterstützen, wenn eine große Anzahl von in die Warteschlange gestellten Aufgaben abgebrochen wird.</Dd>

<dt>Reclamation</dt>

<dd>A pool that is no longer referenced in a program <em>AND</em> has no remaining threads may be reclaimed (garbage collection) without being explicitly shutdown. Sie können einen Pool so konfigurieren, dass alle nicht verwendeten Threads schließlich sterben können, indem Sie geeignete Keep-Alive-Zeiten festlegen, indem Sie eine untere Grenze von Nullkernthreads und/oder -einstellungen verwenden #allowCoreThreadTimeOut(boolean). </Dd>

</Dl>

<b Erweiterungsbeispiel>.</b> Die meisten Erweiterungen dieser Klasse setzen mindestens eine der geschützten Hookmethoden außer Kraft. Hier ist beispielsweise eine Unterklasse, die ein einfaches Feature zum Anhalten/Fortsetzen hinzufügt:

{@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();
                }
              }
            }}

Hinzugefügt in 1.5.

Java-Dokumentation für java.util.concurrent.ThreadPoolExecutor.

Teile dieser Seite sind Änderungen auf der Grundlage von Arbeiten, die vom Android Open Source-Projekt erstellt und freigegeben werden und gemäß den in der Creative Commons 2.5 Attribution License beschriebenen Begriffen verwendet werden.

Konstruktoren

Eigenschaften

Methoden

Explizite Schnittstellenimplementierungen

Erweiterungsmethoden

Gilt für: