Ejecutor.newCachedThreadPool () versus Ejecutores.Nuevo conjunto de herramientas()

Solo para completar las otras respuestas, me gustaría citar Effective Java, 2a Edición, por Joshua Bloch, capítulo 10, Ítem 68:

"Elegir el servicio ejecutor para una aplicación en particular puede ser complicado. Si estás escribiendo un pequeño programa, o servidor ligeramente cargado, con Ejecutores.new-CachedThreadPool es generalmente una buena opción, ya que no requiere configuración y generalmente "hace lo correcto."Pero un grupo de subprocesos en caché es no es una buena opción para un servidor de producción muy cargado!

En un grupo de subprocesos en caché, las tareas enviadas no se ponen en cola sino que se entregan inmediatamente a un subproceso para su ejecución. Si no hay hilos disponibles, se crea uno nuevo. Si un servidor está tan cargado que todas sus CPU se utilizan completamente, y llegan más tareas, se crearán más subprocesos, lo que solo empeorará las cosas.

Por lo tanto, en un servidor de producción , es mucho mejor usar Ejecutores .newFixedThreadPool , que le da un grupo con un número fijo de hilos, o usando la clase ThreadPoolExecutor directamente, para un control máximo."

Si ves el código en el grepcode, verás que están llamando a ThreadPoolExecutor. internamente y estableciendo sus propiedades. Usted puede crear su uno para tener un mejor control de su requisito.

public static ExecutorService newFixedThreadPool(int nThreads) {
   return new ThreadPoolExecutor(nThreads, nThreads,0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>());
}

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

Así es, Executors.newCachedThreadPool() no es una gran opción para el código de servidor que da servicio a múltiples clientes y solicitudes simultáneas.

¿Por qué? Hay básicamente dos problemas (relacionados) con él:

1. No tiene límites, lo que significa que está abriendo la puerta para que cualquiera lisie su JVM simplemente inyectando más trabajo en el servicio (ataque DoS). Los hilos consumen una cantidad no despreciable de memoria y también aumentan el consumo de memoria en función de su trabajo en curso, por lo que es bastante fácil de derribar un servidor de esta manera (a menos que tenga otros disyuntores en su lugar).

2. El problema ilimitado se ve exacerbado por el hecho de que el Ejecutor está encabezado por un SynchronousQueue, lo que significa que hay una transferencia directa entre el dador de tareas y el grupo de subprocesos. Cada nueva tarea creará un nuevo hilo si todos los hilos existentes están ocupados. Esta es generalmente una mala estrategia para el código del servidor. Cuando la CPU se satura, las tareas existentes tardan más en terminar. Sin embargo, se están realizando más tareas enviado y más hilos creados, por lo que las tareas tardan más y más en completarse. Cuando la CPU está saturada, más hilos definitivamente no es lo que el servidor necesita.

Aquí están mis recomendaciones:

Utilice un grupo de subprocesos de tamaño fijo Ejecutores.newFixedThreadPool o un ThreadPoolExecutor. con un número máximo establecido de hilos;

Si no te preocupa la cola ilimitada de tareas Llamables/Ejecutables, puedes usar una de ellas. Como sugiere Bruno, yo también prefiero newFixedThreadPool a newCachedThreadPool entre estos dos.

Pero ThreadPoolExecutor proporciona características más flexibles en comparación con newFixedThreadPool o newCachedThreadPool

ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, 
TimeUnit unit, BlockingQueue<Runnable> workQueue, ThreadFactory threadFactory,
RejectedExecutionHandler handler)

Ventajas:

1. Tienes control total sobre el tamaño de BlockingQueue . No está sin límite a diferencia de las dos opciones anteriores. No voy a salir de error de memoria debido a la enorme acumulación de tareas pendientes ejecutables/ejecutables en turbulencias inesperadas en el sistema.

2. Puede implementar una política personalizada de manejo de rechazo O usar una de las políticas:

   1. En el valor predeterminado ThreadPoolExecutor.AbortPolicy, el controlador lanza una excepción en tiempo de ejecución RejectedExecutionException tras el rechazo.

   2. En ThreadPoolExecutor.CallerRunsPolicy, el subproceso que invoca a execute ejecuta la tarea. Esto proporciona un mecanismo de control de retroalimentación simple que ralentizará la califique que se envían nuevas tareas.

   3. En ThreadPoolExecutor.DiscardPolicy, una tarea que no se puede ejecutar simplemente se elimina.

   4. En ThreadPoolExecutor.DiscardOldestPolicy, si el ejecutor no se apaga, la tarea a la cabeza de la cola de trabajo se cae, y luego se vuelve a intentar la ejecución (lo que puede fallar de nuevo, causando que esto se repita.)

3. Puede implementar la fábrica de hilos personalizados para los siguientes casos de uso:

   1. Para establecer un nombre de hilo más descriptivo
   2. Para establecer estado del demonio de hilo
   3. Para establecer la prioridad del hilo

Debe usar newCachedThreadPool solo cuando tenga tareas asíncronas de corta duración como se indica en Javadoc, si envía tareas que tardan más tiempo en procesarse, terminará creando demasiados subprocesos. Puede alcanzar el 100% de CPU si envía tareas de ejecución larga a un ritmo más rápido a newCachedThreadPool (http://rashcoder.com/be-careful-while-using-executors-newcachedthreadpool/).

Hago algunas pruebas rápidas y tengo los siguientes hallazgos:

1) si se usa SynchronousQueue:

Después de que los hilos alcancen el tamaño máximo, cualquier trabajo nuevo será rechazado con la excepción como abajo.

Excepción en el hilo "main" java.útil.concurrente.RejectedExecutionException: Task java.útil.concurrente.FutureTask@3fee733d rechazado desde java.útil.concurrente.ThreadPoolExecutor@5acf9800 [Ejecución , tamaño del grupo = 3, hilos activos = 3, tareas en cola = 0, tareas completadas = 0]

En java.útil.concurrente.ThreadPoolExecutor Ab AbortPolicy.Ejecución rechazada (ThreadPoolExecutor.java:2047)

2) si se usa LinkedBlockingQueue:

Los hilos nunca aumentan de tamaño mínimo a tamaño máximo, lo que significa que el grupo de hilos es de tamaño fijo como el tamaño mínimo.