Vantaggi degli esecutori rispetto alla nuova discussione

Question

Quali vantaggi è possibile utilizzare gli esecutori tramite solo thread in un programma Java.

Come

ExecutorService pool = Executors.newFixedThreadPool(2); 
void someMethod() { 
    //Thread 
    new Thread(new SomeRunnable()).start(); 

    //vs 

    //Executor 
    pool.execute(new SomeRunnable()); 
} 

Vuol un esecutore solo limitare il numero di thread che permette di avere in esecuzione in una sola volta (Thread Pooling)? In realtà esegue multiplex sui thread che crea invece? Se no, è solo un modo per evitare di dover scrivere ogni volta un nuovo Thread (eseguibile) .start()?

Answer 1

Sì, gli esecutori eseguiranno in genere multiplex sui thread che creano; essi vincoleranno e gestiranno il numero di thread in esecuzione contemporaneamente; renderà molto più facile personalizzare i livelli di concorrenza. Generalmente, gli executors dovrebbero essere preferiti semplicemente creando solo thread nudi.

Answer 2

La creazione di nuovi thread è costosa. Poiché gli Executor utilizzano un pool di thread, è possibile riutilizzare facilmente i thread, con un conseguente miglioramento delle prestazioni.

Answer 3

Un executor limita solo il numero di thread che consente di eseguire contemporaneamente (Thread Pooling)?

Executors#newFixedThreadPool(int), Executors#newSingleThreadExecutor fare questo, ognuno in termini diversi (leggi il corretto javadoc per saperne di più).

In realtà esegue multiplex sui thread che crea invece?

Sì

Se non è solo un modo per evitare di dover scrivere nuovo Discussione (eseguibile) .start() ogni volta?

ExecutorService consente di controllare il modo in cui gestisci i thread. Certo, puoi farlo manualmente, ma non è necessario reinventare la ruota. Inoltre, ci sono altre funzionalità che ExecutorService ti offre come eseguire attività asincrone tramite l'utilizzo delle istanze Future.

Answer 4

Come ho detto sopra in a related question, i thread sono piuttosto negativi. Esecutori (e le relative classi di concorrenza) sono piuttosto buone:

Avvertenza: qui intorno, scoraggiamo fortemente l'uso di thread grezzi. I preferisco di gran lunga l'uso di Callables e FutureTasks (da javadoc: "A calcolo asincrono cancellabile"). L'integrazione dei timeout, l'annullamento corretto di e il pooling di thread del supporto di concorrenza moderno sono tutti molto più utili per me rispetto alle pile di thread non elaborati.

Per esempio, io sto attualmente sostituendo un pezzo eredità di codice che ha utilizzato un filo disgiunti in esecuzione in un ciclo con un autoscatto per determinare quanto tempo dovrebbe Thread.Sleep() dopo ogni iterazione. La mia sostituzione userà un Runnable molto semplice (per mantenere una singola iterazione), uno ScheduledExecutorService per eseguire una delle iterazioni e lo Future risultante dal metodo scheduleAtAFixedRate per regolare il tempo tra le iterazioni.

Mentre si potrebbe sostenere che la sostituzione sarà effettivamente equivalente al codice legacy, avrò sostituito un arcano ringhio di gestione Thread e pio desiderio con un set di funzionalità compartimentate che separa le preoccupazioni della GUI (siamo attualmente in esecuzione?) dall'elaborazione dei dati (riproduzione a velocità 5x) e gestione dei file (annullare questa corsa e scegliere un altro file).

Answer 5

Ci sono diversi problemi relativi al thread.

• gestione fili
• utilizzo delle risorse
• creazione di filo

Executors fornisce diversi tipi di applicazione per creare un pool di thread. Anche la creazione di thread è costosa. Gli esecutori creano e gestiscono internamente questi thread. Dettagli su di esso possono essere trovati nel link sottostante. http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadPoolExecutor.html