metodo newCachedThreadPool

Un altro tipo di pool di thread è "memorizzato nella cache". Tali pool di thread sono usati altrettanto comunemente di quelli fissi.

Come indicato dal nome, questo tipo di pool di thread memorizza nella cache i thread. Mantiene attivi i thread inutilizzati per un periodo di tempo limitato al fine di riutilizzarli per eseguire nuove attività. Un tale pool di thread è il migliore per quando abbiamo una quantità ragionevole di lavoro leggero.

Il significato di "una quantità ragionevole" è piuttosto ampio, ma dovresti sapere che un tale pool non è adatto a tutti i compiti. Ad esempio, supponiamo di voler creare un milione di attività. Anche se ognuno richiede una quantità di tempo molto ridotta, utilizzeremo comunque una quantità irragionevole di risorse e degraderemo le prestazioni. Dovremmo anche evitare tali pool quando il tempo di esecuzione è imprevedibile, ad esempio con le attività di I/O.

Sotto il cofano, il costruttore ThreadPoolExecutor viene chiamato con i seguenti argomenti:

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

I seguenti valori vengono passati al costruttore come argomenti:

E possiamo passare la nostra implementazione di ThreadFactory esattamente allo stesso modo.

Parliamo di SynchronousQueue

L'idea di base di un trasferimento sincrono è piuttosto semplice e tuttavia controintuitiva (ovvero, l'intuizione o il buon senso ti dice che è sbagliato): puoi aggiungere un elemento a una coda se e solo se un altro thread riceve l' elemento al contemporaneamente. In altre parole, una coda sincrona non può contenere attività, perché non appena arriva una nuova attività, il thread in esecuzione ha già prelevato l'attività .

Quando una nuova attività entra nella coda, se c'è un thread attivo libero nel pool, riprende l'attività. Se tutti i thread sono occupati, viene creato un nuovo thread.

Un pool memorizzato nella cache inizia con zero thread e può potenzialmente crescere fino a thread Integer.MAX_VALUE . In sostanza, la dimensione di un pool di thread memorizzato nella cache è limitata solo dalle risorse di sistema.

Per conservare le risorse di sistema, i pool di thread memorizzati nella cache rimuovono i thread inattivi per un minuto.

Vediamo come funziona in pratica. Creeremo una classe di attività che modella una richiesta utente:

public class Task implements Runnable {
   int taskNumber;

   public Task(int taskNumber) {
       this.taskNumber = taskNumber;
   }

   @Override
   public void run() {
       System.out.println("Processed user request #" + taskNumber + " on thread " + Thread.currentThread().getName());
   }
}

Nel metodo principale , creiamo newCachedThreadPool e quindi aggiungiamo 3 attività per l'esecuzione. Qui stampiamo lo stato del nostro servizio (1) .

Successivamente, ci fermiamo per 30 secondi, avviamo un'altra attività e visualizziamo lo stato (2) .

Successivamente, mettiamo in pausa il nostro thread principale per 70 secondi, stampiamo lo stato (3) , quindi aggiungiamo nuovamente 3 attività e stampiamo nuovamente lo stato (4) .

Nei punti in cui mostriamo lo stato subito dopo l'aggiunta di un'attività, aggiungiamo prima una sospensione di 1 secondo per l'output aggiornato.

ExecutorService executorService = Executors.newCachedThreadPool();
        for (int i = 0; i < 3; i++) {
            executorService.submit(new Task(i));
        }

        TimeUnit.SECONDS.sleep(1);
            System.out.println(executorService);	//(1)

        TimeUnit.SECONDS.sleep(30);

        executorService.submit(new Task(3));
        TimeUnit.SECONDS.sleep(1);
            System.out.println(executorService);	//(2)

        TimeUnit.SECONDS.sleep(70);

            System.out.println(executorService);	//(3)

        for (int i = 4; i < 7; i++) {
            executorService.submit(new Task(i));
        }

        TimeUnit.SECONDS.sleep(1);
            System.out.println(executorService);	//(4)
        executorService.shutdown();

Ed ecco il risultato:

Esaminiamo ciascuno dei passaggi:

Bene, ora conosci la logica di un altro tipo di servizio esecutore.

Per analogia con altri metodi della classe di utilità Executors , anche il metodo newCachedThreadPool ha una versione in overload che accetta un oggetto ThreadFactory come argomento.