Sono nuovo a ScheduledThreadPoolExecutor (come di solito uso il semplice Timer, ma le persone lo hanno sconsigliato), e non capisco bene quale sarebbe l'intero appropriato valore da passare al costruttore ScheduledThreadPoolExecutor(int).significato di 'core pool size' nel costruttore ScheduledThreadPoolExecutor
Qualcuno potrebbe spiegarlo?
si
Grazie sostanza, il corePoolSize è il numero di thread per mantenere in piscina.
es. se si prevedono 10 richieste simultanee su base regolare, ma con picchi di 20. CorePoolSize dovrebbe essere 10 e max come 20. In questo modo l'executor creerà fino a 10 nuovi thread, anche se i thread inattivi sono disponibili per l'uso.
Come indicato nella JavaDocs
Core e massima del pool formati
Un ThreadPoolExecutor regolerà automaticamente la dimensione del pool (vedi getPoolSize()) secondo i limiti stabiliti dalla corePoolSize (vedi getCorePoolSize()) e maximumPoolSize (vedere getMaximumPoolSize()). Quando una nuova attività viene inoltrata nel metodo execute (java.lang.Runnable) e meno di quelli corePoolSize sono in esecuzione, viene creato un nuovo thread per gestire la richiesta, anche se altri thread worker sono inattivi. Se ci sono più di corePoolSize ma meno di maximumPoolSize thread 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. Impostando maximumPoolSize su un valore sostanzialmente non limitato come Integer.MAX_VALUE, si consente al pool di ospitare un numero arbitrario di attività simultanee. In genere, le dimensioni del pool principale e massimo sono impostate solo al momento della costruzione, ma possono anche essere modificate in modo dinamico utilizzando setCorePoolSize (int) e setMaximumPoolSize (int).
Sfortunatamente ScheduledThreadPoolExecutor non tratta questi parametri gli stessi ThreadPoolExecutor . STPE funge da pool di thread fisso di dimensioni 'corePoolSize' e non crea alcun thread aggiuntivo. maximumPoolSize non fa nulla. –
Riprendendo l'affermazione di Mike Q su questo.Sembra che l'implementazione di Java di ScheduledThreadPoolExecutor sia carente in questo senso. L'inoltro solo di un conteggio principale non imposterà il conteggio massimo nell'API getMaximumPoolSize e restituirà Integer.MAX_VALUE, che sembra un'API non funzionante se core e max devono sempre essere uguali. Perché dovrebbero implementare anche l'interfaccia ThreadPoolExecutor se non era destinata a essere utilizzata? – Hazok
@Hazok, infatti 'maxPoolSize' non viene modificato, ma il suo valore non viene rispettato dall'implementazione e il reale' corePoolSize' verrà utilizzato come conteggio dei thread massimo. – Antoniossss
In caso di ScheduledThreadPoolExecutor, corePoolSize è il numero massimo di thread che saranno creati per eseguire azioni programmate. Questo pool di thread è di dimensioni fisse e i thread inattivi sono mantenuti in vita.
risposta di DrunkenRabbit è semplicemente ivalid perché ScheduledThreadPoolsExecutor docs dice esplicitamente che (Non ci sarà nessun filo Coun picchi a tutti):
Mentre questa classe eredita da ThreadPoolExecutor, alcuni dei metodi di sintonia ereditati non sono utile per questo. In particolare, perché funge da pool di dimensioni fisse utilizzando i thread corePoolSize e una coda senza limiti, le rettifiche a maximumPoolSize non hanno alcun effetto utile.
Ora come per il valore, il numero ragionevole sarebbe il numero di core CPU su cui è in esecuzione l'applicazione.
Per riferimento: http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ScheduledThreadPoolExecutor.html#ScheduledThreadPoolExecutor(int) –