| Wiki Markup |
|---|
A {{ThreadGroup}} is nothing but a group of threads as defined by the class {{java.lang.ThreadGroup}}. A group is assigned to a thread upon its creation. If the group name is not specified explicitly, the default group called {{main}} is assigned by the JVM. One can use the The convenience methods of the {{ThreadGroup}} class can be used to operate on all threads at once, such as, by using the {{interrupt}} method. Another use is to build in layered security by confining threads into groups so that they do not interfere with each other.
\[[JavaThreads 04|AA. Java References#JavaThreads 04]\] |
| Wiki Markup |
|---|
While there may be a few benefits, the associated dangers demand a deeper insight into the real utility of the {{ThreadGroup}} class. Several of the {{ThreadGroup}} APIs ({{allowThreadSuspension, resume, stop, suspend}}) have been deprecated and the remainder are seldom used due to little desirable functionality. Ironically, a few APIs are not even thread-safe. \[[Bloch 01|AA. Java References#Bloch 01]\] |
| Wiki Markup |
|---|
A programmer may sometimes wish to enumerate all the threads in a group as a precursor to other operations. This is accomplished by using the {{activeCount}} method that "Returns an estimate of the number of active threads in this thread group. " \[[API 06|AA. Java References#API 06]\]. Notice that there is no absolute word on whether it returns the exact count or not; the definition of _active_ also has a different connotation here. A thread that has beenis constructed and not started is still counted by the {{activeCount}} method as _active_. |
| Wiki Markup |
|---|
According to the Java API \[[API 06|AA. Java References#API 06]\], Class {{ThreadGroup}} documentation: |
The
enumeratemethod "Copies into the specified array every active thread in this thread group and its subgroups. An application should use theactiveCountmethod 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."
| Wiki Markup |
|---|
Threads are removed from the thread array either when they are stopped or when their {{run}} method has concluded. As a result, if a thread is not started, it willcontinues continue to reside in the array despite the loss of the original reference. \[[JavaThreads 99|AA. Java References#JavaThreads 99]\] |
...
This noncompliant code example shows a NetworkHandler class that maintains a controller thread. This thread is responsible for spawning a new thread every time a new network connection request is received. For the sake of brevity, it is assumed that the controller thread invokes two methods (method1() and method2()) in succession and waits for a few milliseconds. The method1() method creates and starts two threads that are equivalent to two consequent connection requests, and so does the method2() method. All threads are defined to belong to the same group, Chief.
There is a Time of Check-Time of Use (TOCTOU) vulnerability in this implementation since because obtaining the count and enumerating the list are do not constitute an atomic operation. If new requests come in during the time interval between calling activeCount() and enumerate(), the total number of threads in the group will increase but there would be only two thread references in the enumerated list ta. Print statements have been added before the invocation of activecount() and enumerate() to show this effect. Different runs of the program would produce different values due to because of the race conditions and demonstrate how a few incoming requests can get completely ignored. Any subsequent usage use of the ta array would may lead to undesirable object retention.
...
| Wiki Markup |
|---|
To be compliant, avoid using the {{ThreadGroup}} class. Before Java 5.0, this class had to be extended as there was no other way to control the {{UncaughtExceptionHandler}}. This application provided handler comes into picture when a thread exits duebecause toof an uncaught exception. In recent versions, the {{UncaughtExceptionHandler}} is maintained on a per-thread basis using an interface enclosed by the {{Thread}} class, leaving little to no functionality for the {{ThreadGroup}} class. \[[Goetz 06|AA. Java References#Goetz 06]\] |
...
Using the ThreadGroup APIs may result in race conditions, memory leakage leaks and inconsistent object state.
...