powinna być ustawiona na usługę ExecutorService jako globalna i globalna

Question

Chcę używać tej samej puli wątków w całej mojej aplikacji. W tym celu mogę uczynić ExecutorService statyczną i globalną, dzięki czemu mogę wywołać ThreadUtil.executorService, aby uzyskać ExecutorService, gdy jest to potrzebne.

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

Czy można instancję wielu pul wątków w ten sposób?

Ponadto moją aplikacją jest serwer TCP. Jeśli nie wiem, jak duża powinna być pula, czy można po prostu użyć newCachedThreadPool?

Answer 1

Gdy instancja o takich samych właściwościach ma być używana w dowolnym miejscu w programie, logiczne jest zadeklarowanie jej jako statycznej i ostatecznej zamiast ponownego tworzenia instancji za każdym razem.

Co do drugiego zapytania, nie widzę z nim żadnego problemu. Pierwsze zdanie w dokumentacji newCachedThreadPool mówi

Tworzy puli wątków, które tworzy nowe wątki, ile potrzeba

ponieważ nie wiem, jak wiele wątków zostanie utworzony, jest to najbardziej logicznym wyborem .

Pamiętaj, że newCachedThreadPool użyje starych wątków, gdy będą dostępne w celu zwiększenia wydajności.

Answer 2

Nie zrobiłbym tego bezpośrednio globalnie. Przynajmniej zawiń go w klasę, abyś mógł z łatwością korzystać z więcej niż jednej puli. Posiadanie puli wątków jest bardzo przydatne, gdy potrzebujesz więcej niż jednego rodzaju zadań/zadań o innym priorytecie. Po prostu umieść mniej wątków w innych wątkach puli i/lub wątku o niższym priorytecie (przez przejechanie przez fabrykę wątków). Dla próbki można zobaczyć https://github.com/tgkprog/ddt/tree/master/DdtUtils/src/main/java/org/s2n/ddt/util/threads

Zastosowanie:

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

również nie korzystają z pamięci podręcznej basen, ponieważ może rosnąć w miarę potrzeb, nie jest dobrym pomysłem z TCP, które mogą blokować przez czas nieokreślony. Chcesz użyć kontrolowanej puli. W razie potrzeby powyższą bibliotekę można ponownie zainicjować (zwiększyć liczbę wątków, zezwalając bieżącym zadaniom na przetwarzanie, zanim stara pula zostanie odrzucona do GC).

można wykonać użytkową JSP/serwletu dla tych ops jak https://github.com/tgkprog/ddt/blob/master/Core/src/main/web/common/poolEnd.jsp i https://github.com/tgkprog/ddt/blob/master/Core/src/main/web/common/threads.jsp

Answer 3

Jeśli masz tylko ExecutorServivce dla danej aplikacji, można przystąpić statyczny globalny.

newCachedThreadPool() i newFixedThreadPool() zarówno nie zapewnia kontroli nad kolejnością zadań Callable/Runnable. Używają nieograniczonej kolejki, co może spowodować pogorszenie wydajności systemu pod względem wydajności.

Preferuję używać ThreadPoolExecutor, który zapewnia lepszą kontrolę nad różnymi parametrami, takimi jak Wielkość kolejki, obsługa odrzuceń, fabryka wątków itd.

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

Albo

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

Patrz poniżej słupka więcej szczegółów:

FixedThreadPool vs CachedThreadPool: the lesser of two evils