FixedThreadPool vs CachedThreadPool: el menor de dos males

Tengo un programa que genera subprocesos (~ 5-150) que realizan un montón de tareas. Originalmente, usé un FixedThreadPoolporque esta pregunta similar sugería que eran más adecuados para tareas de mayor duración y, con mi conocimiento muy limitado de subprocesos múltiples, consideré que la vida media de los subprocesos (varios minutos) era "de larga duración ".

Sin embargo, recientemente agregué la capacidad de generar subprocesos adicionales y hacerlo me lleva por encima del límite de subprocesos que establecí. En este caso, ¿sería mejor adivinar y aumentar el número de subprocesos que puedo permitir o cambiar a uno CachedThreadPoolpara no tener subprocesos desperdiciados?

Probándolos a ambos de manera preliminar, no parece haber una diferencia, así que me inclino a ir con los CachedThreadPooljustos para evitar el desperdicio. Sin embargo, ¿la vida útil de los subprocesos significa que debería elegir un FixedThreadPoolsubproceso y simplemente ocuparme de los subprocesos no utilizados? Esta pregunta hace que parezca que esos hilos adicionales no se desperdician, pero agradecería la aclaración.

Un CachedThreadPool es exactamente lo que debe usar para su situación, ya que no hay consecuencias negativas al usar uno para hilos de larga ejecución. El comentario en el documento de java acerca de que CachedThreadPools es adecuado para tareas cortas simplemente sugiere que son particularmente apropiados para tales casos, no que no puedan o no deban usarse para tareas que involucran tareas de larga ejecución.

Para desarrollar más, Executors.newCachedThreadPool y Executors.newFixedThreadPool están respaldados por la misma implementación del grupo de subprocesos (al menos en el JDK abierto) solo con diferentes parámetros. Las diferencias son el mínimo, el máximo, el tiempo de eliminación del subproceso y el tipo de cola.

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>());
}

Un FixedThreadPool tiene sus ventajas cuando, de hecho, desea trabajar con un número fijo de subprocesos, ya que entonces puede enviar cualquier número de tareas al servicio ejecutor sabiendo que el número de subprocesos se mantendrá en el nivel que especificó. Si desea explícitamente aumentar el número de subprocesos, esta no es la opción adecuada.

Sin embargo, esto significa que el único problema que puede tener con CachedThreadPool es limitar el número de subprocesos que se ejecutan al mismo tiempo. CachedThreadPool no los limitará por usted, por lo que es posible que deba escribir su propio código para asegurarse de no ejecutar demasiados subprocesos. Esto realmente depende del diseño de su aplicación y cómo se envían las tareas al servicio ejecutor.

Ambos FixedThreadPooly CachedThreadPoolson males en aplicaciones muy cargadas.

CachedThreadPool es mas peligroso que FixedThreadPool

Si su aplicación está muy cargada y exige baja latencia, es mejor deshacerse de ambas opciones debido a los inconvenientes siguientes

1. Naturaleza ilimitada de la cola de tareas: puede causar falta de memoria o alta latencia
2. Los subprocesos de ejecución prolongada harán CachedThreadPoolque se salga de control en la creación del subproceso

Como sabes que ambos son males, el mal menor no hace el bien. Prefiera ThreadPoolExecutor , que proporciona un control granular sobre muchos parámetros.

1. Configure la cola de tareas como cola limitada para tener un mejor control
2. Tenga el RejectionHandler correcto: su propio RejectionHandler o los controladores predeterminados proporcionados por JDK
3. Si tiene algo que hacer antes o después de completar la tarea, anule beforeExecute(Thread, Runnable)yafterExecute(Runnable, Throwable)
4. Invalidar ThreadFactory si se requiere personalizar hilo
5. Controle el tamaño del grupo de subprocesos dinámicamente en tiempo de ejecución (pregunta de SE relacionada: grupo de subprocesos dinámico )

Entonces tengo un programa que genera subprocesos (~ 5-150) que realizan un montón de tareas.

¿Está seguro de que comprende cómo el sistema operativo y el hardware de su elección procesan los subprocesos? ¿Cómo asigna Java los subprocesos a los subprocesos del sistema operativo, cómo eso asigna los subprocesos a los subprocesos de la CPU, etc.? Lo pregunto porque crear 150 subprocesos dentro de ONE JRE solo tiene sentido si tiene núcleos / subprocesos de CPU masivos debajo, lo que probablemente no sea el caso. Dependiendo del sistema operativo y la RAM en uso, la creación de más de n subprocesos podría incluso provocar la terminación de su JRE debido a errores OOM. Por lo tanto, realmente debería distinguir entre los subprocesos y el trabajo a realizar por esos subprocesos, cuántos trabajos incluso puede procesar, etc.

Y ese es el problema con CachedThreadPool: no tiene sentido poner en cola el trabajo de larga ejecución en subprocesos que en realidad no se pueden ejecutar porque solo tiene 2 núcleos de CPU capaces de procesar esos subprocesos. Si termina con 150 subprocesos programados, puede crear una gran cantidad de gastos generales innecesarios para que los programadores utilizados en Java y el sistema operativo los procesen simultáneamente. Esto es simplemente imposible si solo tiene 2 núcleos de CPU, a menos que sus subprocesos estén esperando E / S o algo así todo el tiempo. Pero incluso en ese caso, muchos subprocesos crearían una gran cantidad de E / S ...

Y ese problema no ocurre con FixedThreadPool, creado, por ejemplo, con 2 + n subprocesos, donde n es razonablemente bajo, por supuesto, porque con ese hardware y los recursos del sistema operativo se utilizan con mucha menos sobrecarga para administrar subprocesos que no pueden ejecutarse de todos modos.