Page History

Wiki MarkupEach thread in Java is assigned to a thread group upon the thread's creation. These groups are implemented by the {{java.lang.ThreadGroup}} class. If When the thread group name is not specified explicitly, the {{main}} default group is assigned by the JVM \[[Tutorials 2008|AA. Java References#Tutorials 08]\]. 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 {{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 do not interfere with threads in other groups \[[JavaThreads 2004|AA. Java References#JavaThreads 04]\].

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

Insecure yet non-deprecated methods include

*{{ThreadGroup.activeCount()}}
According to the Java API, the {{activeCount()}} method \[[API 2006|AA. Java References#API 06]\]  

...

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, allowThreadSuspension(), resume(), stop(), and 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

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

  returns an estimate of the number of active threads in

...

• the current thread's thread group

...

• and its subgroups.

  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 activeCount() method might fail to reflect the actual number of running tasks in the thread group.

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

  [The enumerate() method] copies into the specified array every active thread in this thread group and its subgroups....
  An application might use the activeCount method 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.

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]:

This method is often used as a precursor to thread enumeration.  If a thread is not started, it continues to reside in the thread group and is considered to be active. Furthermore, the active count is affected by the presence of certain system threads \[[API 2006|AA. Java References#API 06]\]. Consequently, the _{{activeCount()}}_ method may not reflect the actual number of running tasks in the thread group.

*{{ThreadGroup.enumerate()}}
According to the Java API, {{ThreadGroup}} class documentation \[[API 2006|AA. Java References#API 06]\]

Wiki Markup
\[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.

Wiki MarkupUsing the {{ThreadGroup}} APIs to shut down threads also has pitfalls. Because the {{stop()}} method is deprecated, alternative ways are required to stop threads. According to The Java Programming Language \[[JPL 2006|AA. Java References#JPL 06]\]

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.

Wiki MarkupThe {{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|AA. Java References#Bloch 08]\]]. Consequently, programs must not invoke ThreadGroup methods.

Noncompliant Code Example

This noncompliant code example contains a NetworkHandler class that maintains a controller thread. This The controller thread delegates a each new request to a worker thread. To demonstrate the race condition in this example, the controller thread services serves three requests by starting three threads in succession from its run() method. All threads are defined to belong to the Chief thread group.

final class HandleRequest implements Runnable {
  public void run() {
    // Do something
  }
}


public final class NetworkHandler implements Runnable {
  private static ThreadGroup tg = new ThreadGroup("Chief");

  @Override public void run() {
    new Thread(tg, new HandleRequest(), "thread1").start(); // Start thread 1
    new Thread(tg, new HandleRequest(), "thread2").start(); // Start thread 2
    new Thread(tg, new HandleRequest(), "thread3").start(); // Start thread 3
  }

  public static void printActiveCount(int point) {
    System.out.println("Active Threads in Thread Group " + tg.getName() +
        " at point(" + point + "):" + " " + tg.activeCount());
  }

  public static void printEnumeratedThreads(Thread[] ta, int len) {
    System.out.println("Enumerating all threads...");
    for (int i = 0; i < len; i++) {
      System.out.println("Thread " + i + " = " + ta[i].getName());
    }
  }

  public static void main(String[] args) throws InterruptedException {
    // Start thread controller
    Thread thread = new Thread(tg, new NetworkHandler(), "controller"); 
    thread.start();

    // Gets the active count (insecure)
    Thread[] ta = new Thread[tg.activeCount()]; // Gets the active count (insecure)

    printActiveCount(1);           // P1
    Thread.sleep(1000);            // Delay to demonstrate TOCTOU condition (race window)
    printActiveCountThread.sleep(21000);      
     // P2: the thread count changes as new threads are initiated
    printActiveCount(2);  
    // Incorrectly uses the (now stale) thread count obtained at P1
    int n = tg.enumerate(ta);  
    printEnumeratedThreads(ta, n); // Silently ignores newly initiated threads 
    printEnumeratedThreads(ta, n); 
                                   // (between P1 and P2)

    // This code destroys the thread group if it does 
    // not have any alivelive threads
    for (Thread thr : ta) {
      thr.interrupt();
      while(thr.isAlive());
    }
    tg.destroy();
  }
}

There is This implementation contains a time-of-check-to-, time-of-use (TOCTOU) vulnerability in this implementation because obtaining it obtains the count and enumerating enumerates the list do not constitute an atomic operationwithout ensuring atomicity. If one or more new requests occurs 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 will would increase, but the enumerated list ta will would contain only the initial number, that is, two thread references (: main and controller). Consequently, the program will would fail to account for the newly started threads in the Chief thread group.

Any subsequent use of the ta array is would be insecure. For example, calling the destroy() method to destroy the thread group and its sub-groups will subgroups would not work as expected. The precondition to calling destroy() is that the thread group is must be empty with no executing threads. The code attempts to accomplish this comply with the precondition by interrupting every thread in the thread group. However, the thread group would not be empty when the destroy() method is was called, the thread group is not empty, which causes 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. Note that there are no Although the interface lacks methods for finding the number of actively executing threads or for enumerating through them. Howeverthe 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 can be terminated by calling the shutdownPool() method.

public final class NetworkHandler {
  private final ExecutorService executor;

  NetworkHandler(int poolSize) {
    this.executor = Executors.newFixedThreadPool(poolSize);
  }

  public void startThreads() {
    for (int i = 0; i < 3; i++) {
      executor.execute(new HandleRequest());
    }
  }

  public void shutdownPool() {
    executor.shutdown();
  }

  public static void main(String[] args)  {
    NetworkHandler nh = new NetworkHandler(3);
    nh.startThreads();
    nh.shutdownPool();
  }
}

...

Before Java SE 5.0, the {{ThreadGroup}} class had to be extended because there was no other direct way to catch an uncaught exception in a separate thread. If the application had installed an {{UncaughtExceptionHandler}}, it could only be controlled by subclassing {{ThreadGroup}}. In recent versions,{{UncaughtExceptionHandler}} is maintained on a per-thread basis using an interface enclosed by the {{Thread}} class, which leaves little to no functionality for the {{ThreadGroup}} class \[[Goetz 2006|AA. Java References#Goetz 06]\], \[[Bloch 2008|AA. Java References#Bloch 08]\].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 Refer to guideline 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.

Risk Assessment

Using Use of the ThreadGroup APIs may result in race conditions, memory leaks, and inconsistent object state.

References

...

Automated Detection

Bibliography

...

...

...

...

...

...

...

...

...

...

...

...

...

Image Added Image Added |AA. Java References#SDN 06]\] Bug ID: 4089701 and 4229558 \[[Tutorials 2008|AA. Java References#Tutorials 08]\]THI00-J. Do not assume that the sleep(), yield() or getState() methods provide synchronization semantics      12. Locking (LCK)      Image Modified