Parece imposible hacer un grupo de subprocesos en caché con un límite en el número de subprocesos que puede crear.
Así es como se implementa Executors.newCachedThreadPool estático en la biblioteca estándar de Java:
public static ExecutorService newCachedThreadPool() {
return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
60L, TimeUnit.SECONDS,
new SynchronousQueue<Runnable>());
}
Entonces, usando esa plantilla para crear un grupo de subprocesos en caché de tamaño fijo:
new ThreadPoolExecutor(0, 3, 60L, TimeUnit.SECONDS, new SynchronusQueue<Runable>());
Ahora, si usa esto y envía 3 tareas, todo estará bien. El envío de cualquier otra tarea dará como resultado excepciones de ejecución rechazadas.
Intentando esto:
new ThreadPoolExecutor(0, 3, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue<Runable>());
El resultado será que todos los hilos se ejecuten secuencialmente. Es decir, el grupo de subprocesos nunca hará más de un subproceso para manejar sus tareas.
Este es un error en el método de ejecución de ThreadPoolExecutor? O tal vez esto es intencional? ¿O hay alguna otra manera?
Editar: quiero algo exactamente como el grupo de subprocesos en caché (crea subprocesos bajo demanda y luego los mata después de un tiempo de espera) pero con un límite en el número de subprocesos que puede crear y la capacidad de continuar haciendo cola tareas adicionales una vez que ha golpear su límite de hilo. Según la respuesta de sjlee, esto es imposible. Mirando el método execute () de ThreadPoolExecutor, es realmente imposible. Necesitaría subclasificar ThreadPoolExecutor y anular execute () de manera similar a SwingWorker, pero lo que SwingWorker hace en execute () es un hack completo.