agrupaciones de hilos individuales o múltiples para el servidor Java?

Question

Estoy escribiendo una aplicación de servidor Java bastante compleja que tiene una porción de procesamiento de fondo significativa además del procesamiento habitual de solicitud-respuesta. Parte del procesamiento en segundo plano se realiza en forma de cron utilizando Quartz framework. Otras tareas son más de demanda: si un nuevo cliente se conecta, crea trabajo adicional para actualizarlo de vez en cuando. Las tareas de cron también se pueden modificar: algunas supervisan aplicaciones externas, otras calculan estadísticas, etc.

Estoy usando varios grupos de subprocesos para ejecutar todos esos trabajos con la idea de que trabajos similares compartirán un grupo de subprocesos pero diferentes trabajos no compartirán uno. Por ejemplo, los trabajos de monitor nunca se ejecutarán en el grupo de estadísticas, y los trabajos de estadísticas nunca se ejecutarán en el grupo de monitores.

Por otro lado, sé que algunas personas preferirían tener solo un grupo de subprocesos y ejecutar todo sin ninguna separación.

Me pregunto qué se considera la mejor práctica en tal escenario.

¿Cuáles son los pros y las desventajas de separar las piscinas de hilos?

¿Importa?

Answer 1

En realidad no es una respuesta directa, pero otra propuesta :-(

Sus trabajos de cuarzo se pueden pausar, cancelados y así sucesivamente, vamos a llamarlo "lograron". Creo que se va a crear un poco de interfaz de usuario para Administrelos

¿Se da cuenta de que sus otros trabajos ("bajo demanda") no se beneficiarán de las mismas funcionalidades, a menos que lo implemente? ¿Consideró que todo era un trabajo de cuarzo (incluso si se inicia de inmediato), para obtener un código uniforme?

Answer 2

La respuesta depende de si necesita segregar o no los recursos de la aplicación entre diferentes tipos de actividad.

Por ejemplo, actualmente estoy escribiendo una aplicación de servidor que consiste en algunos escritores de alto rendimiento y potencialmente muchos lectores. Los lectores accederán a la aplicación de forma esporádica, pero podrían solicitar una gran cantidad de datos (es decir, solicitudes de larga ejecución). Necesito asegurarme de que los escritores nunca se mueran de hambre, así que voy a utilizar dos grupos de hilos en mi diseño para leer/escribir. Si el grupo de subprocesos del lector se agota temporalmente, los escritores no se verán afectados; solo las solicitudes de lectura se retrasarán.

Una alternativa habría sido utilizar un PriorityQueue en conjunción con un ThreadPoolExecutor y asignar una mayor prioridad a las solicitudes de escritura.

Por lo tanto, en conclusión: Mi consejo sería: Comience con un grupo de subprocesos y solo haga su diseño más complejo si hay una razón concreta para hacerlo.