ThreadPoolExecutor Klasse

Referenz

Definition

Namespace:: Java.Util.Concurrent

Assembly:: Mono.Android.dll

Wichtig

Einige Informationen beziehen sich auf Vorabversionen, die vor dem Release ggf. grundlegend überarbeitet werden. Microsoft übernimmt hinsichtlich der hier bereitgestellten Informationen keine Gewährleistungen, seien sie ausdrücklich oder konkludent.

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

[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> Direct Handoffs. 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> Ungebundene Warteschlangen. 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>bounded queues. 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> 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 AND 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>

. 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

ThreadPoolExecutor(Int32, Int32, Int64, TimeUnit, IBlockingQueue)	Erstellt eine neue `ThreadPoolExecutor` mit den angegebenen Anfangsparametern, der Executors#defaultThreadFactory-Standardthread-Threadfactory und dem ThreadPoolExecutor.
ThreadPoolExecutor(Int32, Int32, Int64, TimeUnit, IBlockingQueue, IRejectedExecutionHandler)	Erstellt eine neue `ThreadPoolExecutor` mit den angegebenen Anfangsparametern und der StandardthreadFactory-Threadfactory-Factory für Executors#defaultThreadFactory.
ThreadPoolExecutor(Int32, Int32, Int64, TimeUnit, IBlockingQueue, IThreadFactory)	Erstellt ein neues `ThreadPoolExecutor` mit den angegebenen Anfangsparametern und dem ThreadPoolExecutor.
ThreadPoolExecutor(Int32, Int32, Int64, TimeUnit, IBlockingQueue, IThreadFactory, IRejectedExecutionHandler)	Erstellt ein neues `ThreadPoolExecutor` mit den angegebenen Anfangsparametern.
ThreadPoolExecutor(IntPtr, JniHandleOwnership)	Ein Konstruktor, der beim Erstellen verwalteter Darstellungen von JNI-Objekten verwendet wird; wird von der Laufzeit aufgerufen.

Eigenschaften

ActiveCount	Gibt die ungefähre Anzahl von Threads zurück, die aktiv Aufgaben ausführen.
Class	Gibt die Laufzeitklasse dieses Werts `Object`zurück. (Geerbt von Object)
CompletedTaskCount	Gibt die ungefähre Gesamtzahl der Aufgaben zurück, die die Ausführung abgeschlossen haben.
CorePoolSize	Gibt die Kernanzahl von Threads zurück. -or- Legt die Kernanzahl von Threads fest.
Handle	Das Handle für die zugrunde liegende Android-Instanz. (Geerbt von Object)
IsShutdown	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert.
IsTerminated	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert.
IsTerminating	Gibt true zurück, wenn sich dieser Executor im Prozess des Beendens nach `#shutdown` oder `#shutdownNow` aber nicht vollständig beendet hat.
JniIdentityHashCode	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert. (Geerbt von Object)
JniPeerMembers	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert.
LargestPoolSize	Gibt die größte Anzahl von Threads zurück, die sich jemals im Pool befinden.
MaximumPoolSize	Gibt die maximal zulässige Anzahl von Threads zurück. - oder- Legt die maximal zulässige Anzahl von Threads fest.
PeerReference	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert. (Geerbt von Object)
PoolSize	Gibt die aktuelle Anzahl von Threads im Pool zurück.
Queue	Gibt die von diesem Executor verwendete Aufgabenwarteschlange zurück.
RejectedExecutionHandler	Gibt den aktuellen Handler für nicht ausgeführte Vorgänge zurück. - oder- Legt einen neuen Handler für nicht ausgeführte Aufgaben fest.
TaskCount	Gibt die ungefähre Gesamtzahl der Vorgänge zurück, die jemals für die Ausführung geplant wurden.
ThreadFactory	Gibt die Threadfactory zurück, die zum Erstellen neuer Threads verwendet wird. - oder- Legt die Threadfactory fest, die zum Erstellen neuer Threads verwendet wird.
ThresholdClass	Diese API unterstützt die Mono für Android-Infrastruktur und ist nicht für die direkte Verwendung aus Ihrem Code vorgesehen.
ThresholdType	Diese API unterstützt die Mono für Android-Infrastruktur und ist nicht für die direkte Verwendung aus Ihrem Code vorgesehen.

Methoden

AfterExecute(IRunnable, Throwable)	Methode, die nach Abschluss der Ausführung des angegebenen Runnable aufgerufen wird.
AllowCoreThreadTimeOut(Boolean)	Legt die Richtlinie fest, die festlegt, ob Kernthreads ein Timeout und Beenden können, wenn keine Aufgaben innerhalb der Keep-Alive-Zeit eingehen und bei Bedarf ersetzt werden, wenn neue Vorgänge eingehen.
AllowsCoreThreadTimeOut()	Gibt "true" zurück, wenn dieser Pool das Timeout von Kernthreads ermöglicht und beendet werden kann, wenn keine Vorgänge innerhalb der keepAlive-Zeit eingehen, wenn neue Vorgänge eingehen.
AwaitTermination(Int64, TimeUnit)	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert.
AwaitTerminationAsync(Int64, TimeUnit)	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert. (Geerbt von AbstractExecutorService)
BeforeExecute(Thread, IRunnable)	Die Methode, die vor dem Ausführen des angegebenen Runnable-Werts im angegebenen Thread aufgerufen wurde.
Clone()	Erstellt und gibt eine Kopie dieses Objekts zurück. (Geerbt von Object)
Dispose()	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert. (Geerbt von Object)
Dispose(Boolean)	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert. (Geerbt von Object)
Equals(Object)	Gibt an, ob ein anderes Objekt "gleich" diesem Objekt ist. (Geerbt von Object)
Execute(IRunnable)	Führt die angegebene Aufgabe irgendwann in der Zukunft aus.
GetHashCode()	Gibt einen Hashcodewert für das Objekt zurück. (Geerbt von Object)
GetKeepAliveTime(TimeUnit)	Gibt die Thread-Keep-Alive-Zeit zurück, d. h. die Zeitspanne, die Threads im Leerlauf bleiben können, bevor sie beendet werden.
InvokeAll(ICollection)	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert. (Geerbt von AbstractExecutorService)
InvokeAll(ICollection, Int64, TimeUnit)	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert. (Geerbt von AbstractExecutorService)
InvokeAny(ICollection)	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert. (Geerbt von AbstractExecutorService)
InvokeAny(ICollection, Int64, TimeUnit)	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert. (Geerbt von AbstractExecutorService)
JavaFinalize()	Wird vom Garbage Collector für ein Objekt aufgerufen, wenn die Garbage Collection bestimmt, dass keine weiteren Verweise auf das Objekt vorhanden sind. (Geerbt von Object)
NewTaskFor(ICallable)	Gibt einen `RunnableFuture` Wert für den angegebenen aufrufbaren Vorgang zurück. (Geerbt von AbstractExecutorService)
NewTaskFor(IRunnable, Object)	Gibt einen `RunnableFuture` Wert für den angegebenen Runnable- und Standardwert zurück. (Geerbt von AbstractExecutorService)
Notify()	Aktiviert einen einzelnen Thread, der auf dem Monitor dieses Objekts wartet. (Geerbt von Object)
NotifyAll()	Aktiviert alle Threads, die auf dem Monitor dieses Objekts warten. (Geerbt von Object)
PrestartAllCoreThreads()	Startet alle Kernthreads, sodass sie idly auf arbeit warten.
PrestartCoreThread()	Startet einen Kernthread, sodass er idly auf die Arbeit wartet.
Purge()	Versucht, alle `Future` Vorgänge, die abgebrochen wurden, aus der Arbeitswarteschlange zu entfernen.
Remove(IRunnable)	Entfernt diese Aufgabe aus der internen Warteschlange des Executors, wenn sie vorhanden ist, sodass sie nicht ausgeführt wird, wenn sie noch nicht gestartet wurde.
SetHandle(IntPtr, JniHandleOwnership)	Legt die Handle-Eigenschaft fest. (Geerbt von Object)
SetKeepAliveTime(Int64, TimeUnit)	Legt die Thread-Keep-Alive-Zeit fest, d. h. die Zeitspanne, die Threads im Leerlauf bleiben können, bevor sie beendet werden.
Shutdown()	Initiiert ein geordnetes Herunterfahren, in dem zuvor übermittelte Aufgaben ausgeführt werden, aber keine neuen Aufgaben werden akzeptiert.
ShutdownNow()	Versucht, alle aktiv ausgeführten Aufgaben zu beenden, die Verarbeitung von Wartevorgängen anzuhalten und gibt eine Liste der Aufgaben zurück, die auf die Ausführung warten.
Submit(ICallable)	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert. (Geerbt von AbstractExecutorService)
Submit(IRunnable)	Sendet eine ausführungsfähige Aufgabe und gibt eine Zukunft zurück, die diese Aufgabe darstellt. (Geerbt von AbstractExecutorService)
Submit(IRunnable, Object)	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert. (Geerbt von AbstractExecutorService)
Terminated()	Die Methode wird aufgerufen, wenn der Executor beendet wurde.
ToArray<T>()	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert. (Geerbt von Object)
ToString()	Gibt eine Zeichenfolgendarstellung des Objekts zurück. (Geerbt von Object)
UnregisterFromRuntime()	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert. (Geerbt von Object)
Wait()	Bewirkt, dass der aktuelle Thread wartet, bis er wach ist, in der Regel durch em benachrichtigt/em> oder <em>unterbrochen</em>.<>< (Geerbt von Object)
Wait(Int64)	Bewirkt, dass der aktuelle Thread wartet, bis er wach ist, in der Regel durch <em>benachrichtigt</em> oder <em>unterbrochen</em> oder bis eine bestimmte Menge an Echtzeit verstrichen ist. (Geerbt von Object)
Wait(Int64, Int32)	Bewirkt, dass der aktuelle Thread wartet, bis er wach ist, in der Regel durch <em>benachrichtigt</em> oder <em>unterbrochen</em> oder bis eine bestimmte Menge an Echtzeit verstrichen ist. (Geerbt von Object)

Explizite Schnittstellenimplementierungen

IJavaPeerable.Disposed()	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert. (Geerbt von Object)
IJavaPeerable.DisposeUnlessReferenced()	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert. (Geerbt von Object)
IJavaPeerable.Finalized()	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert. (Geerbt von Object)
IJavaPeerable.JniManagedPeerState	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert. (Geerbt von Object)
IJavaPeerable.SetJniIdentityHashCode(Int32)	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert. (Geerbt von Object)
IJavaPeerable.SetJniManagedPeerState(JniManagedPeerStates)	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert. (Geerbt von Object)
IJavaPeerable.SetPeerReference(JniObjectReference)	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert. (Geerbt von Object)

Erweiterungsmethoden

JavaCast<TResult>(IJavaObject)	Führt eine android-laufzeitgecheckte Typkonvertierung aus.
JavaCast<TResult>(IJavaObject)	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert.
GetJniTypeName(IJavaPeerable)	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert.
AwaitTerminationAsync(IExecutorService, Int64, TimeUnit)	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert.
InvokeAnyAsync(IExecutorService, ICollection)	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert.
InvokeAnyAsync(IExecutorService, ICollection, Int64, TimeUnit)	Ein `ExecutorService` Vorgang, der jede übermittelte Aufgabe mit einem von möglicherweise mehreren gepoolten Threads ausführt, normalerweise mit `Executors` Factorymethoden konfiguriert.

Gilt für:

Freigeben über