¿Cuál es el beneficio de ThreadGroup en Java sobre la creación de subprocesos independientes?

Question

Muchos métodos como stop(), resume(), suspend() etc. están en desuso.

¿Es útil crear hilos usando ThreadGroup?

Answer 1

El uso de ThreadGroup puede ser una técnica de diagnóstico útil en los servidores de aplicaciones grandes con miles de subprocesos. Si tus hilos están lógicamente agrupados, cuando obtienes un seguimiento de pila puedes ver de qué grupo forma parte el hilo ofensivo (por ejemplo, "hilos de Tomcat", "hilos de MDB", "grupo de hilos X", etc.), que puede ser una gran ayuda para rastrear y solucionar el problema.

Answer 2

La respuesta corta es - no, en realidad no. Hay poco o ningún beneficio de usar uno.

Para ampliarlo ligeramente, si desea agrupar los hilos de los trabajadores, es mucho mejor utilizar un ExecutorService. Si desea contar rápidamente cuántos subprocesos en un grupo conceptual están vivos, aún necesita verificar cada subproceso individualmente (como ThreadGroup.activeCount() es una estimación, lo que significa que no es útil si la corrección de su código depende de su resultado) .

Me atrevería a decir que lo único que obtendría de uno estos días, aparte de la compartimentación semántica, es que los hilos construidos como parte de un grupo recogerán la bandera daemon y una sensible nombre basado en su grupo. Y usar esto como un atajo para completar algunas primitivas en una llamada de constructor (que normalmente solo tendrías que escribir una vez, sicne probablemente estés iniciando los hilos en un bucle y/o llamada a un método).

Entonces, realmente no veo ningún motivo convincente para usar uno. Lo intenté específicamente, hace unos meses, y fallé.

EDITAR - I suponga un uso potencial sería si está ejecutando con un SecurityManager, y quiere afirmar que solo los hilos en el mismo grupo pueden interrumpirse entre sí. Incluso eso es bastante dudoso, ya que la implementación predeterminada siempre devuelve verdadero para un subproceso en cualquier grupo de subprocesos que no sean del sistema. Y si está implementando su propio SecurityManager, tiene la posibilidad de que tome una decisión sobre cualquier otro criterio (incluida la técnica típica de almacenar Threads en colecciones a medida que se crean).

Answer 3

No utilice ThreadGroup para obtener un código nuevo. Utilice el Executor cosas en java.util.concurrent en su lugar.

Answer 4

Algo complementario a la respuesta brindada (hace 6 años más o menos). Pero, si bien la API de concurrencia proporciona muchas construcciones, el ThreadGroup podría ser útil. Proporciona la siguiente funcionalidad:

1. Organización lógica de sus hilos (con fines de diagnóstico).
2. Puede interrupt() todos los hilos en el grupo. (La interrupción está perfectamente bien, a diferencia de suspend(), resume() y stop()).
3. Puede establecer la prioridad máxima de los hilos en el grupo. (no estoy seguro de cuán útil es eso, pero ahí lo tiene).
4. Establece ThreadGroup como daemon. (Entonces, todos los hilos nuevos añadidos serán hilos daemon).
5. Le permite anular su uncaughtExceptionHandler de modo que si uno de los hilos en el grupo arroja una excepción, tiene una devolución de llamada para manejarlo.
6. Le proporciona algunas herramientas adicionales como obtener la lista de hilos, cuántos activos tiene, etc. Útil cuando tiene un grupo de hilos de trabajo, o algún grupo de hilos de algún tipo.

Answer 5

Excelente answer para @skaffman. Quiero agregar una ventaja más:

Los grupos de subprocesos ayudan a manipular todos los subprocesos que se definen en esto a la vez.

Por ejemplo: puede iniciar o interrumpir todos los hilos dentro de un grupo con una sola llamada a un método.