Impossibile creare un pool di thread nella cache con un limite di dimensioni?

Sembra impossibile creare un pool di thread nella cache con un limite al numero di thread che può creare.

Ecco come viene implementato Executors.newCachedThreadPool statico nella libreria Java standard:

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

Quindi, usando quel modello per continuare a creare un pool di thread nella cache di dimensioni fisse:

new ThreadPoolExecutor(0, 3, 60L, TimeUnit.SECONDS, new SynchronusQueue<Runable>());

Ora se lo usi e invii 3 attività, tutto andrà bene. L'invio di ulteriori attività comporterà eccezioni di esecuzione rifiutate.

Provando questo:

new ThreadPoolExecutor(0, 3, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue<Runable>());

Il risultato sarà l'esecuzione sequenziale di tutti i thread. Vale a dire, il pool di thread non realizzerà mai più di un thread per gestire le attività.

Questo è un bug nel metodo di esecuzione di ThreadPoolExecutor? O forse questo è intenzionale? O c'è un altro modo?

Modifica: voglio qualcosa di simile al pool di thread nella cache (crea thread su richiesta e poi li uccide dopo un certo timeout) ma con un limite al numero di thread che può creare e la possibilità di continuare a mettere in coda attività aggiuntive una volta che ha ha raggiunto il limite del thread. Secondo la risposta di Sjlee questo è impossibile. Guardando il metodo execute () di ThreadPoolExecutor è davvero impossibile. Avrei bisogno di sottoclassare ThreadPoolExecutor e sovrascrivere execute () in qualche modo come fa SwingWorker, ma ciò che SwingWorker fa nel suo execute () è un hack completo.

ThreadPoolExecutor ha i seguenti comportamenti chiave diversi e i tuoi problemi possono essere spiegati da questi comportamenti.

Quando vengono inoltrate attività,

1. Se il pool di thread non ha raggiunto la dimensione del core, crea nuovi thread.
2. Se la dimensione del core è stata raggiunta e non ci sono thread inattivi, mette in coda le attività.
3. Se la dimensione del core è stata raggiunta, non ci sono thread inattivi e la coda si riempie, crea nuovi thread (fino a raggiungere la dimensione massima).
4. Se è stata raggiunta la dimensione massima, non ci sono thread inattivi e la coda si riempie, entra in vigore la politica di rifiuto.

Nel primo esempio, nota che SynchronousQueue ha essenzialmente una dimensione di 0. Pertanto, nel momento in cui raggiungi la dimensione massima (3), inizia la politica di rifiuto (# 4).

Nel secondo esempio, la coda di scelta è LinkedBlockingQueue che ha una dimensione illimitata. Pertanto, rimani bloccato con il comportamento n. 2.

Non puoi davvero armeggiare molto con il tipo memorizzato nella cache o il tipo fisso, poiché il loro comportamento è quasi completamente determinato.

Se si desidera disporre di un pool di thread limitato e dinamico, è necessario utilizzare una dimensione core positiva e una dimensione massima combinate con una coda di dimensioni finite. Per esempio,

new ThreadPoolExecutor(10, // core size
    50, // max size
    10*60, // idle timeout
    TimeUnit.SECONDS,
    new ArrayBlockingQueue<Runnable>(20)); // queue with a size

Addendum : questa è una risposta abbastanza vecchia e sembra che JDK abbia cambiato comportamento quando si tratta di dimensioni del nucleo pari a 0. Da JDK 1.6, se la dimensione del nucleo è 0 e il pool non ha alcun thread, ThreadPoolExecutor aggiungerà un thread per eseguire quell'attività. Pertanto, la dimensione del nucleo di 0 è un'eccezione alla regola sopra. Grazie Steve per averlo portato alla mia attenzione.

A meno che non mi sia perso qualcosa, la soluzione alla domanda originale è semplice. Il codice seguente implementa il comportamento desiderato come descritto dal poster originale. Genererà fino a 5 thread per lavorare su una coda illimitata e i thread inattivi termineranno dopo 60 secondi.

tp = new ThreadPoolExecutor(5, 5, 60, TimeUnit.SECONDS,
                    new LinkedBlockingQueue<Runnable>());
tp.allowCoreThreadTimeOut(true);

Ha avuto lo stesso problema. Poiché nessun'altra risposta mette insieme tutti i problemi, sto aggiungendo il mio:

Ora è chiaramente scritto nei documenti : se si utilizza una coda che non blocca ( LinkedBlockingQueue) l'impostazione dei thread max non ha alcun effetto, vengono utilizzati solo i thread core.

così:

public class MyExecutor extends ThreadPoolExecutor {

    public MyExecutor() {
        super(4, 4, 5,TimeUnit.SECONDS, new LinkedBlockingQueue<Runnable>());
        allowCoreThreadTimeOut(true);
    }

    public void setThreads(int n){
        setMaximumPoolSize(Math.max(1, n));
        setCorePoolSize(Math.max(1, n));
    }

}

Questo esecutore ha:

1. Nessun concetto di thread max poiché stiamo utilizzando una coda illimitata. Questa è una buona cosa perché tale coda può causare all'esecutore la creazione di un numero enorme di thread extra non core se segue la sua politica abituale.

2. Una coda di dimensioni massime Integer.MAX_VALUE. Submit()verrà lanciato RejectedExecutionExceptionse il numero di attività in sospeso supera Integer.MAX_VALUE. Non sono sicuro che prima saremo a corto di memoria o ciò accadrà.

3. Ha 4 thread core possibili. I thread core inattivi terminano automaticamente se inattivi per 5 secondi. Quindi, sì, thread strettamente su richiesta. Il numero può essere variato usando il setThreads()metodo.

4. Si assicura che il numero minimo di thread core non sia mai inferiore a uno, altrimenti submit()rifiuterà ogni attività. Poiché i thread core devono essere> = max thread, il metodo setThreads()imposta anche i thread max, sebbene l'impostazione max thread sia inutile per una coda illimitata.

Nel tuo primo esempio, le attività successive vengono rifiutate perché AbortPolicyè l'impostazione predefinita RejectedExecutionHandler. ThreadPoolExecutor contiene i seguenti criteri, che è possibile modificare tramite il setRejectedExecutionHandlermetodo:

CallerRunsPolicy
AbortPolicy
DiscardPolicy
DiscardOldestPolicy

Sembra che tu voglia un pool di thread nella cache con un CallerRunsPolicy.

Nessuna delle risposte qui risolto il mio problema, che aveva a che fare con la creazione di un numero limitato di connessioni HTTP utilizzando il client HTTP di Apache (versione 3.x). Dal momento che mi ci sono volute alcune ore per capire una buona installazione, condividerò:

private ExecutorService executor = new ThreadPoolExecutor(5, 10, 60L,
  TimeUnit.SECONDS, new SynchronousQueue<Runnable>(),
  Executors.defaultThreadFactory(), new ThreadPoolExecutor.CallerRunsPolicy());

Questo crea un ThreadPoolExecutorche inizia con cinque e contiene un massimo di dieci thread in esecuzione simultaneamente usando CallerRunsPolicyper l'esecuzione.

Per Javadoc per ThreadPoolExecutor:

Se ci sono più di corePoolSize ma meno di maximumPoolSize in esecuzione, verrà creato un nuovo thread solo se la coda è piena . Impostando corePoolSize e maximumPoolSize allo stesso modo, si crea un pool di thread di dimensioni fisse.

(Enfasi mia.)

la risposta di jitter è ciò che vuoi, anche se la mia risponde alla tua altra domanda. :)

c'è un'altra opzione. Invece di usare la nuova SynchronousQueue puoi usare anche qualsiasi altra coda, ma devi assicurarti che la sua dimensione sia 1, in modo da forzare il servizio di esecuzione per creare un nuovo thread.

Non sembra che nessuna delle risposte risponda effettivamente alla domanda - in effetti non riesco a vedere un modo per farlo - anche se si esegue una sottoclasse da PooledExecutorService poiché molti dei metodi / proprietà sono privati, ad esempio rendendo addIfUnderMaximumPoolSize protetto è possibile eseguire le seguenti operazioni:

class MyThreadPoolService extends ThreadPoolService {
    public void execute(Runnable run) {
        if (poolSize() == 0) {
            if (addIfUnderMaximumPoolSize(run) != null)
                return;
        }
        super.execute(run);
    }
}

Il più vicino che ho avuto è stato questo, ma anche questa non è un'ottima soluzione

new ThreadPoolExecutor(min, max, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue<Runnable>()) {
    public void execute(Runnable command) {
        if (getPoolSize() == 0 && getActiveCount() < getMaximumPoolSize()) {        
            super.setCorePoolSize(super.getCorePoolSize() + 1);
        }
        super.execute(command);
    }

    protected void afterExecute(Runnable r, Throwable t) {
         // nothing in the queue
         if (getQueue().isEmpty() && getPoolSize() > min) {
             setCorePoolSize(getCorePoolSize() - 1);
         }
    };
 };

ps non testato quanto sopra

Ecco un'altra soluzione. Penso che questa soluzione si comporti come vuoi tu (anche se non orgogliosa di questa soluzione):

final LinkedBlockingQueue<Runnable> queue = new LinkedBlockingQueue<Runnable>() {
    public boolean offer(Runnable o) {
        if (size() > 1)
            return false;
        return super.offer(o);
    };

    public boolean add(Runnable o) {
        if (super.offer(o))
            return true;
        else
            throw new IllegalStateException("Queue full");
    }
};

RejectedExecutionHandler handler = new RejectedExecutionHandler() {         
    public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
        queue.add(r);
    }
};

dbThreadExecutor =
        new ThreadPoolExecutor(min, max, 60L, TimeUnit.SECONDS, queue, handler);

Questo è quello che vuoi (almeno credo di sì). Per una spiegazione, controlla la risposta di Jonathan Feinberg

Executors.newFixedThreadPool(int n)

Crea un pool di thread che riutilizza un numero fisso di thread che operano su una coda non associata condivisa. In ogni momento, al massimo i thread di nThreads saranno attività di elaborazione attive. Se vengono inviate attività aggiuntive quando tutti i thread sono attivi, attenderanno in coda fino a quando non sarà disponibile un thread. Se un thread termina a causa di un errore durante l'esecuzione prima dell'arresto, ne sostituirà uno nuovo, se necessario, per eseguire le attività successive. I thread nel pool esisteranno fino a quando non verranno esplicitamente arrestati.

1. Puoi usare ThreadPoolExecutorcome suggerito da @sjlee

   È possibile controllare la dimensione del pool in modo dinamico. Dai un'occhiata a questa domanda per maggiori dettagli:

   Pool di thread dinamici

   O

2. È possibile utilizzare la nuova API WorkStealingPool , che è stata introdotta con java 8.

   public static ExecutorService newWorkStealingPool()

   Crea un pool di thread che ruba il lavoro utilizzando tutti i processori disponibili come livello di parallelismo di destinazione.

Per impostazione predefinita, il livello di parallelismo è impostato sul numero di core della CPU nel server. Se si dispone di un server CPU a 4 core, la dimensione del pool di thread sarebbe 4. Questa API restituisce il ForkJoinPooltipo di ExecutorService e consente il furto di thread inattivi rubando attività da thread occupati in ForkJoinPool.

Il problema è stato riassunto come segue:

Voglio qualcosa di esattamente simile al pool di thread nella cache (crea thread su richiesta e poi li uccide dopo un certo timeout) ma con un limite al numero di thread che può creare e la possibilità di continuare a mettere in coda attività aggiuntive una volta che ha colpito il suo limite di thread.

Prima di indicare la soluzione, spiegherò perché le seguenti soluzioni non funzionano:

new ThreadPoolExecutor(0, 3, 60L, TimeUnit.SECONDS, new SynchronousQueue<>());

Questo non metterà in coda alcuna attività quando viene raggiunto il limite di 3 perché SynchronousQueue, per definizione, non può contenere alcun elemento.

new ThreadPoolExecutor(0, 3, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue<>());

Ciò non creerà più di un singolo thread poiché ThreadPoolExecutor crea thread che superano corePoolSize solo se la coda è piena. Ma LinkedBlockingQueue non è mai pieno.

ThreadPoolExecutor executor = new ThreadPoolExecutor(3, 3, 60, TimeUnit.SECONDS,
    new LinkedBlockingQueue<Runnable>());
executor.allowCoreThreadTimeOut(true);

Ciò non riutilizza i thread fino a quando corePoolSize non viene raggiunto perché ThreadPoolExecutor aumenta il numero di thread fino a quando corePoolSize viene raggiunto anche se i thread esistenti sono inattivi. Se riesci a convivere con questo svantaggio, questa è la soluzione più semplice al problema. È anche la soluzione descritta in "Java Concurrency in Practice" (nota in calce a p172).

L'unica soluzione completa al problema descritto sembra essere quella che prevede l'override del offermetodo della coda e la scrittura di un RejectedExecutionHandlercome spiegato nelle risposte a questa domanda: Come ottenere ThreadPoolExecutor per aumentare i thread al massimo prima di mettere in coda?

Funziona con Java8 + (e altri, per ora ..)

     Executor executor = new ThreadPoolExecutor(3, 3, 5, TimeUnit.SECONDS,
                new LinkedBlockingQueue<>()){{allowCoreThreadTimeOut(true);}};

dove 3 è il limite del numero di thread e 5 è il timeout per i thread inattivi.

Se vuoi verificare se funziona da solo , ecco il codice per fare il lavoro:

public static void main(String[] args) throws InterruptedException {
    final int DESIRED_NUMBER_OF_THREADS=3; // limit of number of Threads for the task at a time
    final int DESIRED_THREAD_IDLE_DEATH_TIMEOUT=5; //any idle Thread ends if it remains idle for X seconds

    System.out.println( java.lang.Thread.activeCount() + " threads");
    Executor executor = new ThreadPoolExecutor(DESIRED_NUMBER_OF_THREADS, DESIRED_NUMBER_OF_THREADS, DESIRED_THREAD_IDLE_DEATH_TIMEOUT, TimeUnit.SECONDS,
            new LinkedBlockingQueue<>()) {{allowCoreThreadTimeOut(true);}};

    System.out.println(java.lang.Thread.activeCount() + " threads");

    for (int i = 0; i < 5; i++) {
        final int fi = i;
        executor.execute(() -> waitsout("starting hard thread computation " + fi, "hard thread computation done " + fi,2000));
    }
    System.out.println("If this is UP, it works");

    while (true) {
        System.out.println(
                java.lang.Thread.activeCount() + " threads");
        Thread.sleep(700);
    }

}

static void waitsout(String pre, String post, int timeout) {
    try {
        System.out.println(pre);
        Thread.sleep(timeout);
        System.out.println(post);
    } catch (Exception e) {
    }
}

l'output del codice sopra per me è

1 threads
1 threads
If this is UP, it works
starting hard thread computation 0
4 threads
starting hard thread computation 2
starting hard thread computation 1
4 threads
4 threads
hard thread computation done 2
hard thread computation done 0
hard thread computation done 1
starting hard thread computation 3
starting hard thread computation 4
4 threads
4 threads
4 threads
hard thread computation done 3
hard thread computation done 4
4 threads
4 threads
4 threads
4 threads
3 threads
3 threads
3 threads
1 threads
1 threads