Page History

Each thread in Java is assigned to a thread group upon the thread's creation. These groups are implemented by the java.lang.ThreadGroup class. When the thread group name is not specified explicitly, the main default group is assigned by the Java Virtual Machine (JVM) [Tutorials 2008]. The convenience methods of the ThreadGroup class can be used to operate on all threads belonging to a thread group at once. For instance, the ThreadGroup.interrupt() method interrupts all threads in the thread group. Thread groups also help reinforce layered security by confining threads into groups so that they avoid interference with threads in other groups [JavaThreads 2004].

Even though thread groups are useful for keeping threads organized, programmers seldom benefit from their use because many of the methods of the ThreadGroup class are deprecated (for example, allowThreadSuspension(), resume(), stop(), and suspend()). Furthermore, many nondeprecated methods are obsolete in that they offer little desirable functionality. Ironically, a few ThreadGroup methods are not even thread-safe [Bloch 2001].

Insecure yet nondeprecated methods include

• ThreadGroup.activeCount()
  According to the Java API, the activeCount() method [API 2006]

  returns an estimate of the number of active threads in this thread group.

  This method is often used as a precursor to thread enumeration. Threads that have never started nevertheless reside in the thread group and are considered to be active. The active count is also affected by the presence of certain system threads [API 2006]. Consequently, the activeCount() method might fail to reflect the actual number of running tasks in the thread group.

• ThreadGroup.enumerate()
  According to the Java API, ThreadGroup class documentation [API 2006]

  [The enumerate() method] copies into the specified array every active thread in this thread group and its subgroups. An application should use the activeCount method to get an estimate of how big the array should be. If the array is too short to hold all the threads, the extra threads are silently ignored.

Using the ThreadGroup APIs to shut down threads also has pitfalls. Because the stop() method is deprecated, programs require alternative methods to stop threads. According to The Java Programming Language [JPL 2006]

One way is for the thread initiating the termination to join the other threads and so know when those threads have terminated. However, an application may have to maintain its own list of the threads it creates because simply inspecting the ThreadGroup may return library threads that do not terminate and for which join will not return.

The Executor framework provides a better API for managing a logical grouping of threads and offers secure facilities for handling shutdown and thread exceptions [Bloch 2008]. Consequently, programs must not invoke ThreadGroup methods.

...

Before Java SE 5.0, applications that needed to catch an uncaught exception in a separate thread had to extend the ThreadGroup class because this was the only direct approach to provide the required functionality. Specifically, an application's UncaughtExceptionHandler could only be controlled by subclassing ThreadGroup. In more recent versions of Java, UncaughtExceptionHandler is maintained on a per-thread basis using an interface enclosed by the Thread class. Consequently, the ThreadGroup class provides little unique functionality [Goetz 2006], [Bloch 2008].

Refer to rule TPS03-J. Ensure that tasks executing in a thread pool do not fail silently for more information on using uncaught exception handlers in thread pools.

...

Bibliography

...

      Rule 10: Thread APIs (THI)Image Added      THI02-J. Notify all waiting threads rather than a single thread