dovrebbe ExecutorService essere statico e globale

Question

Desidero utilizzare lo stesso pool di thread in tutta la mia applicazione. A tal fine, posso rendere statico e globale lo ExecutorService in modo da poter invocare ThreadUtil.executorService per ottenere ExecutorService quando ne ho bisogno.

public class ThreadUtil { 
    public static final ExecutorService executorService = Executors.newCachedThreadPool(); 
} 

Va bene per istanza più pool di thread come questo?

Inoltre, la mia applicazione è un server TCP. Se non so quanto dovrebbe essere grande la piscina, è sufficiente usare semplicemente newCachedThreadPool?

Answer 1

Quando un'istanza con le stesse proprietà deve essere utilizzata in qualsiasi punto del programma, è logico dichiararla statica e definitiva anziché ricreare l'istanza ogni volta.

Per quanto riguarda la seconda query, non vedo alcun problema. La prima frase della documentazione per newCachedThreadPool dice

di creare un pool di thread che crea nuove discussioni, se necessario

dal momento che non si sa quanti thread verrà creato, questa è la scelta più logica .

Si noti che newCachedThreadPool riutilizzerà i thread vecchi quando sono disponibili per aumentare le prestazioni.

Answer 2

Non lo farei direttamente globale. Almeno avvolgerlo in una classe in modo da poter utilizzare facilmente più di un pool. Avere un pool di pool di thread è molto utile quando è necessario più di un tipo di lavoro/lavoro con priorità diversa. Basta inserire meno thread nell'altro pool e/o thread con priorità più bassa (scavalcando il thread factory). Per un esempio può vedere https://github.com/tgkprog/ddt/tree/master/DdtUtils/src/main/java/org/s2n/ddt/util/threads

Usage:

//setup 
PoolOptions options = new PoolOptions(); 
options.setCoreThreads(2); 
options.setMaxThreads(33); 
DdtPools.initPool("poolA", options); 
Do1 p = null; 


    // Offer a job: 
    job = new YourJob(); 
    DdtPools.offer("poolA", job); 

Inoltre non utilizzare una piscina in cache come si può crescere in base alle esigenze, non è una buona idea con il protocollo TCP, che può bloccare a tempo indeterminato. Vuoi usare una piscina controllata. La libreria di cui sopra può essere reinizializzata se necessario (aumentare il numero di thread consentendo al processo corrente di essere elaborato prima che il vecchio pool venga scartato a GC).

Può fare un programma di utilità jsp/servlet per quei ops come https://github.com/tgkprog/ddt/blob/master/Core/src/main/web/common/poolEnd.jsp e https://github.com/tgkprog/ddt/blob/master/Core/src/main/web/common/threads.jsp

Answer 3

Se avete solo ExecutorServivce per l'applicazione, è possibile procedere con statica globale.

newCachedThreadPool() e newFixedThreadPool() entrambi non forniscono il controllo sulla coda delle attività Callable/Runnable. Utilizzano la coda illimitata, il che può comportare una riduzione delle prestazioni del sistema rispetto alle prestazioni.

Preferisco utilizzare ThreadPoolExecutor che fornisce un controllo migliore su vari parametri come Dimensione coda, gestore di rifiuto, fabbrica filo ecc.

public ThreadPoolExecutor(int corePoolSize, 
        int maximumPoolSize, 
        long keepAliveTime, 
        TimeUnit unit, 
        BlockingQueue<Runnable> workQueue, 
        RejectedExecutionHandler handler) 

O

public ThreadPoolExecutor(int corePoolSize, 
        int maximumPoolSize, 
        long keepAliveTime, 
        TimeUnit unit, 
        BlockingQueue<Runnable> workQueue, 
        ThreadFactory threadFactory, 
        RejectedExecutionHandler handler) 

Fare riferimento al di sotto del messaggio per ulteriori dettagli:

FixedThreadPool vs CachedThreadPool: the lesser of two evils