FixedThreadPool vs CachedThreadPool: il minore di due mali

Ho un programma che genera thread (~ 5-150) che eseguono una serie di attività. Inizialmente, ho usato un FixedThreadPoolperché questa domanda simile suggeriva che fossero più adatti per attività più longeve e con la mia conoscenza molto limitata del multithreading, consideravo la vita media dei thread (diversi minuti) "di lunga durata ".

Tuttavia, di recente ho aggiunto la possibilità di generare thread aggiuntivi e così facendo mi porta al di sopra del limite di thread che ho impostato. In questo caso, sarebbe meglio indovinare e aumentare il numero di thread che posso consentire o passare a un fileCachedThreadPool modo da non avere thread sprecati?

Provandoli entrambi preliminarmente, non sembra esserci differenza, quindi sono propenso ad andare con il CachedThreadPoolsolo per evitare gli sprechi. Tuttavia, la durata dei thread significa che dovrei invece scegliere FixedThreadPoole occuparmi solo dei thread inutilizzati? Questa domanda fa sembrare che quei thread extra non siano sprecati, ma apprezzerei il chiarimento.

Un CachedThreadPool è esattamente ciò che dovresti usare per la tua situazione in quanto non ci sono conseguenze negative nell'usarne uno per thread a lunga esecuzione. Il commento nel documento java sul fatto che CachedThreadPools sia adatto per attività brevi suggerisce semplicemente che sono particolarmente appropriati per tali casi, non che non possono o non dovrebbero essere usati per attività che implicano attività a lunga esecuzione.

Per approfondire ulteriormente, Executors.newCachedThreadPool ed Executors.newFixedThreadPool sono entrambi supportati dalla stessa implementazione del pool di thread (almeno nel JDK aperto) solo con parametri diversi. Le differenze sono solo il loro thread minimo, massimo, tempo di kill del thread e tipo di coda.

public static ExecutorService newFixedThreadPool(int nThreads) {
     return new ThreadPoolExecutor(nThreads, nThreads,
                                   0L, TimeUnit.MILLISECONDS,
                                   new LinkedBlockingQueue<Runnable>());
 }

public static ExecutorService newCachedThreadPool() {
    return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                 60L, TimeUnit.SECONDS,
                                 new SynchronousQueue<Runnable>());
}

Un FixedThreadPool ha i suoi vantaggi quando in realtà vuoi lavorare con un numero fisso di thread, da allora puoi inviare un numero qualsiasi di attività al servizio esecutore sapendo che il numero di thread verrà mantenuto al livello specificato. Se si desidera esplicitamente aumentare il numero di thread, questa non è la scelta appropriata.

Ciò tuttavia significa che l'unico problema che potresti avere con CachedThreadPool riguarda la limitazione del numero di thread in esecuzione contemporaneamente. Il CachedThreadPool non li limiterà per te, quindi potresti dover scrivere il tuo codice per assicurarti di non eseguire troppi thread. Questo dipende molto dal design della tua applicazione e da come le attività vengono inviate al servizio di esecutore.

Entrambi FixedThreadPoole CachedThreadPoolsono mali in applicazioni altamente caricate.

CachedThreadPool è più pericoloso di FixedThreadPool

Se la tua applicazione è molto caricata e richiede una bassa latenza, è meglio eliminare entrambe le opzioni a causa dei seguenti inconvenienti

1. Natura illimitata della coda delle attività: potrebbe causare memoria insufficiente o latenza elevata
2. I thread a esecuzione prolungata faranno CachedThreadPoolandare fuori controllo durante la creazione del thread

Poiché sai che entrambi sono mali, il male minore non fa bene. Preferire ThreadPoolExecutor , che fornisce un controllo granulare su molti parametri.

1. Imposta la coda delle attività come coda delimitata per avere un controllo migliore
2. Avere il diritto RejectionHandler: i propri gestori RejectionHandler o Default forniti da JDK
3. Se hai qualcosa da fare prima / dopo il completamento dell'attività, sovrascrivi beforeExecute(Thread, Runnable)eafterExecute(Runnable, Throwable)
4. Eseguire l' override di ThreadFactory se è richiesta la personalizzazione del thread
5. Controllare le dimensioni del pool di thread dinamicamente in fase di esecuzione (domanda SE correlata: pool di thread dinamico )

Quindi ho un programma che genera thread (~ 5-150) che eseguono una serie di attività.

Sei sicuro di aver capito come i thread vengono effettivamente elaborati dal tuo sistema operativo e hardware preferito? In che modo Java associa i thread ai thread del sistema operativo, come associa i thread ai thread della CPU, ecc.? Sto chiedendo perché la creazione di 150 thread all'interno di ONE JRE ha senso solo se si hanno enormi core / thread della CPU sotto, il che molto probabilmente non è il caso. A seconda del sistema operativo e della RAM in uso, la creazione di più di n thread potrebbe persino causare la chiusura di JRE a causa di errori OOM. Quindi dovresti davvero distinguere tra thread e lavoro da fare da quei thread, quanti lavori sei persino in grado di elaborare ecc.

E questo è il problema con CachedThreadPool: non ha senso mettere in coda il lavoro a lunga esecuzione in thread che in realtà non possono essere eseguiti perché hai solo 2 core CPU in grado di elaborare quei thread. Se ti ritrovi con 150 thread pianificati, potresti creare un sovraccarico non necessario per gli scheduler utilizzati in Java e il sistema operativo per elaborarli contemporaneamente. Questo è semplicemente impossibile se hai solo 2 core della CPU, a meno che i tuoi thread non stiano aspettando I / O o cose del genere tutto il tempo. Ma anche in quel caso molti thread creerebbero molto I / O ...

E quel problema non si verifica con FixedThreadPool, creato ad esempio con 2 + n thread, dove n è ovviamente abbastanza basso, perché con quell'hardware e le risorse del sistema operativo vengono utilizzate con molto meno overhead per la gestione di thread che non possono essere eseguiti comunque.