The Java Programming Language uses ThreadGroup to manage the threads access rights to each other:
A thread group represents a set of threads. In addition, a thread group can also include other thread groups. The thread groups form a tree in which every thread group except the initial thread group has a parent.
A thread is allowed to access information about its own thread group, but not to access information about its thread group’s parent thread group or any other thread groups.
I think I understand it, but is this useful in any way? I wonder whether revealing the current ThreadGroup structure and its elements, thus the threads and other ThreadGroup, hold any information from a debugging perspective.
I have found it handy although it’s quite bugged. It can be useful for providing management content b/c the threads created will be added to the parent thread’s ThreadGroup (and can be efficiently enumerated). It can be used to prevent new Thread spawning (but it’s not documented or intended).
Unfortunately ThreadGroup has quite a few bugs, incl. destroy() method.
In short, if you are not going to write middleware, don’t bother. If you need to enumerate all the threads in an application use
Thread.getAllStackTraces().keySet(), the method has a security hole though but I am not discussing this part.Edit: I missed the debugging aspect:
ThreadGroups are actually useful for debugging purposes if the debugging tools allows for tree-view and grouping by the ThreadGroup (for example eclipse does so). Provided you use it properly, all your threads in the currently debugged module/mbean/etc should be in the same group. It allows easier tracking of thread leaks (compared to looking at hundred other threads)