2011-09-20 15 views
5

Sto cercando di capire il punto in cui specificare il core separato e le dimensioni massime del pool per ThreadPoolExecutor di Java 5. La mia comprensione è che il numero di thread è aumentato solo quando la coda è piena, il che sembra un po 'in ritardo (almeno con code più grandi).Quando si specificano le dimensioni del pool principale e massimo in ThreadPoolExecutor una buona idea?

Non è che sia felice di assegnare un numero maggiore di thread alle attività, nel qual caso potrei semplicemente aumentare la dimensione del pool principale; o non sono davvero disposto a farlo, nel qual caso dovrei avere una coda più grande? Qual è uno scenario in cui le dimensioni del core e del pool massimo sono utili?

risposta

2

La differenza è che se si è sotto la dimensione del pool principale, ogni nuova attività crea un nuovo thread indipendentemente dai thread inattivi nel pool. Il numero di thread viene aumentato solo quando la coda è piena quando hai già raggiunto le dimensioni del pool principale ma sono ancora al massimo.

L'esempio perfetto è quando si dispone di un sistema che non si conosce esattamente il carico simultaneo che avrà (ad esempio un server web). Questa funzione consente di specificare un set di thread principale, forse in base al numero di core della macchina, ma consente un carico maggiore di quanto previsto.

Questo è particolarmente utile se si dispone di un carico I/O maggiore di quanto previsto e i thread nel pool impiegano molto tempo. La coda può facilmente essere riempita senza avere un grande carico concorrente in questo scenario, ed è facilmente risolvibile aggiungendo un paio di nuovi thread per soddisfare alcune richieste simultanee.

+1

Ma poi potrei eseguire con più thread per iniziare - altrimenti aggiungo semplicemente la latenza alle attività in attesa in coda. Sospetto anche che in molti scenari in cui la coda si riempie potrebbe riempirsi velocemente, nel qual caso i thread aggiuntivi potrebbero arrivare troppo tardi. –

+0

@Peter, se l'analisi statica è sufficiente per prevedere il numero corretto di thread da utilizzare in un carico eccessivo e sei contento di avere quei thread in più seduti durante il normale caricamento, quindi fallo! È un compromesso tra un tempo di spin-up del thread una tantum sotto carico o un utilizzo extra di risorse quando il carico è basso. – Bringer128

4

C'è una discussione su questo here.

La piscina è destinato a lavorare in condizioni di carico normale a corePoolSize (a cui rampe fino a meno che non viene utilizzato pre-partenza). Quando si verifica una condizione di sovraccarico (definita dal fatto che ci sono più attività in sospeso/in-process rispetto ai lavoratori) utilizziamo la coda per fungere da buffer - con l' attesa che il normale carico di lavoro venga ripristinato nel prossimo futuro. Se siamo preoccupati per un sovraccarico eccessivo, possiamo usare una coda limitata e che dice "se la coda si riempie aggiungere più lavoratori fino a maxPoolSize". Se usiamo una coda illimitata, diciamo che non dobbiamo aspettarci (o altrimenti non preoccuparti) un eccessivo sovraccarico di .

L'obiettivo è quello di bilanciare la capacità di gestire il carico di lavoro previsto, anche sotto sovraccarichi istantanei, senza avere eccessivi creazione filo e senza troppo churn filo (cioè creare-lavoro-die-creare).

+0

Il link è morto? –

+1

Questa è una spiegazione eccellente! Corretto il link morto La discussione indicata nella risposta può essere trovata su http://comments.gmane.org/gmane.comp.java.jsr.166-concurrency/7109 – Shailendra

Problemi correlati