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) [Java Tutorials]. 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 (for example,
suspend()) are deprecated. 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
According to the Java API [API 2014], the
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 2014]. Consequently, the
returns an estimate of the number of active threads in the current thread's thread group and its subgroups.
activeCount()method might fail to reflect the actual number of running tasks in the thread group.
According to the Java API [API 2014],
enumerate()method] copies into the specified array every active thread in this thread group and its subgroups....
An application might use the
activeCountmethod to get an estimate of how big the array should be; however, if the array is too short to hold all the threads, the extra threads are silently ignored.
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
ThreadGroupmay return library threads that do not terminate and for which join will not return.
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
Noncompliant Code Example
This noncompliant code example contains a
NetworkHandler class that maintains a
controller thread. The
controller thread delegates each new request to a worker thread. To demonstrate the race condition in this example, the
controller thread serves three requests by starting three threads in succession from its
run() method. All threads are defined to belong to the
Chief thread group.
This implementation contains a time-of-check, time-of-use (TOCTOU) vulnerability because it obtains the count and enumerates the list without ensuring atomicity. If one or more new requests were to occur after the call to
activeCount() and before the call to
enumerate() in the
main() method, the total number of threads in the group would increase, but the enumerated list
ta would contain only the initial number, that is, two thread references:
controller. Consequently, the program would fail to account for the newly started threads in the
Chief thread group.
Any subsequent use of the
ta array would be insecure. For example, calling the
destroy() method to destroy the thread group and its subgroups would not work as expected. The precondition to calling
destroy() is that the thread group must be empty with no executing threads. The code attempts to comply with the precondition by interrupting every thread in the thread group. However, the thread group would not be empty when the
destroy() method was called, causing a
java.lang.IllegalThreadStateException to be thrown.
This compliant solution uses a fixed thread pool rather than a
ThreadGroup to group its three tasks. The
java.util.concurrent.ExecutorService interface provides methods to manage the thread pool. Although the interface lacks methods for finding the number of actively executing threads or for enumerating the threads, the logical grouping can help control the behavior of the group as a whole. For instance, invoking the
shutdownPool() method terminates all threads belonging to a particular thread pool.
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 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.
Use of the
ThreadGroup APIs may result in race conditions, memory leaks, and inconsistent object state.
|S3014||"ThreadGroup" should not be used|
Item 53, "Avoid Thread Groups"
Item 73, "Avoid Thread Groups"
Section 7.3.1, "Uncaught Exception Handlers"
Section 13.1, "
Section 23.3.3, "Shutdown Strategies"
Bug ID 4089701