sollte ExecutorService statische und globale sein

Question

Ich möchte den gleichen Thread-Pool in meiner gesamten Anwendung verwenden. Zu diesem Zweck kann ich ExecutorService statisch und global machen, so dass ich ThreadUtil.executorService aufrufen kann, um ExecutorService zu bekommen, wenn ich es brauche.

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

Ist es in Ordnung, mehrere Thread-Pools so zu instanziieren?

Darüber hinaus ist meine Anwendung ein TCP-Server. Wenn ich nicht weiß, wie groß der Pool sein sollte, ist es in Ordnung, einfach newCachedThreadPool zu verwenden?

Answer 1

Wenn eine Instanz mit denselben Eigenschaften überall in Ihrem Programm verwendet werden soll, ist es logisch, sie als statisch und final zu deklarieren, anstatt die Instanz jedes Mal neu zu erstellen.

Wie für Ihre zweite Abfrage sehe ich kein Problem damit. Der erste Satz der Dokumentation für newCachedThreadPool sagt

einen Thread-Pool erstellt, die als neue Threads erstellt

benötigt

da Sie nicht wissen, wie viele Threads erstellt wird, ist dies die logischste Wahl .

Beachten Sie, dass newCachedThreadPool alte Threads wieder verwendet, wenn sie verfügbar sind, um die Leistung zu erhöhen.

Answer 2

Ich würde es nicht direkt global machen. Umschließen Sie es zumindest in einer Klasse, sodass Sie problemlos mehr als einen Pool verwenden können. Ein Pool von Thread-Pools ist sehr nützlich, wenn Sie mehr als eine Art von Jobs/Jobs mit unterschiedlicher Priorität benötigen. Fügen Sie einfach weniger Threads in den anderen Pool und/oder Threads mit niedrigerer Priorität ein (durch Überfahren der Thread-Factory). Für eine Probe kann https://github.com/tgkprog/ddt/tree/master/DdtUtils/src/main/java/org/s2n/ddt/util/threads

Nutzungs siehe:

//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); 

auch keinen im Cache-Pool verwenden, da es je nach Bedarf wachsen kann, nicht eine gute Idee, mit TCP, die auf unbestimmte Zeit blockieren kann. Sie möchten einen kontrollierten Pool verwenden. Die obige Bibliothek kann bei Bedarf neu initialisiert werden (erhöhen Sie die Anzahl der Threads, während aktuelle Jobs verarbeitet werden können, bevor der alte Pool zum GC verworfen wird).

Kann ein Dienstprogramm jsp/Servlet für die ops wie https://github.com/tgkprog/ddt/blob/master/Core/src/main/web/common/poolEnd.jsp und https://github.com/tgkprog/ddt/blob/master/Core/src/main/web/common/threads.jsp

Answer 3

machen Wenn Sie nur ExecutorServivce für Ihre Anwendung haben, können Sie mit statischen globalen fortfahren können.

newCachedThreadPool() und newFixedThreadPool() beide bietet keine Kontrolle über die Warteschlange von Callable/Runnable Aufgaben. Sie verwenden die unbegrenzte Warteschlange, die zu einer Leistungsminderung des Systems in Bezug auf die Leistung führen kann.

Ich bevorzuge die Verwendung ThreadPoolExecutor, die eine bessere Kontrolle über verschiedene Parameter wie Warteschlange Größe, Ablehnung Handler, Thread-Fabrik usw. bietet

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

Oder

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

Siehe unten Beitrag für weitere Informationen:

FixedThreadPool vs CachedThreadPool: the lesser of two evils