Menu
Argh I hate it when people say "don't use ThreadGroup". It's like saying "don't use Threads". A thread has a ThreadGroup, there's no getting around that, so unless you want to have a program with no threads, you are using ThreadGroups. I agree we need a question to address when, how and why not to use them.
ThreadGroup creates a group of threads. It offers a convenient way to manage groups of threads as a unit. This is particularly valuable in situation in which you want to suspend and resume a number of related threads. The thread group form a tree in which every thread group except the initial thread group has a parent.
Java provides a convenient way to group multiple threads in a single object. In such a way, we can suspend, resume or interrupt a group of threads by a single method call.
A thread pool reuses previously created threads to execute current tasks and offers a solution to the problem of thread cycle overhead and resource thrashing. Since the thread is already existing when the request arrives, the delay introduced by thread creation is eliminated, making the application more responsive.
This is explained in Effective Java 2nd Ed., Item 73.
Thread groups were originally envisioned as a mechanism for isolating applets for security purposes. They never really fulfilled this promise, and their security importance has waned to the extent that they aren’t even mentioned in the standard work on the Java security model [Gong03].
[...] In an ironic twist, the
ThreadGroupAPI is weak from a thread safety standpoint. To get a list of the active threads in a thread group, you must invoke theenumeratemethod, which takes as a parameter an array large enough to hold all the active threads. TheactiveCountmethod returns the number of active threads in a thread group, but there is no guarantee that this count will still be accurate once an array has been allocated and passed to theenumeratemethod. If the thread count has increased and the array is too small, theenumeratemethod silently ignores any threads for which there is no room in the array.The API that lists the subgroups of a thread group is similarly flawed. While these problems could have been fixed with the addition of new methods, they haven’t, because there is no real need: thread groups are obsolete.
Prior to release 1.5, there was one small piece of functionality that was available only with the
ThreadGroupAPI: theThreadGroup.uncaughtExceptionmethod was the only way to gain control when a thread threw an uncaught exception. This functionality is useful, for example, to direct stack traces to an application- specific log. As of release 1.5, however, the same functionality is available withThread’ssetUncaughtExceptionHandlermethod.To summarize, thread groups don’t provide much in the way of useful functionality, and much of the functionality they do provide is flawed. Thread groups are best viewed as an unsuccessful experiment, and you should simply ignore their existence. If you design a class that deals with logical groups of threads, you should probably use thread pool executors (Item 68).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With