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.  If 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 {{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]\].

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

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

Using 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]\]

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|AA. Java References#Bloch 08]\].

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();

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

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

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

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]\].

\[[API 2006|AA. Java References#API 06]\] Methods {{activeCount}} and {{enumerate}}, Classes ThreadGroup and Thread
\[[Bloch 01|AA. Java References#Bloch 01]\] Item 53: Avoid thread groups
\[[Bloch 2008|AA. Java References#Bloch 08]\] Item 73: Avoid thread groups
\[[Goetz 2006|AA. Java References#Goetz 06]\] Section 7.3.1, "Uncaught Exception Handlers"
\[[JavaThreads 04|AA. Java References#JavaThreads 04]\] 13.1 ThreadGroups
\[[JPL 2006|AA. Java References#JPL 06]\] 23.3.3. Shutdown Strategies
\[[SDN 2006|AA. Java References#SDN 06]\] Bug ID: 4089701 and 4229558
\[[Tutorials 2008|AA. Java References#Tutorials 08]\]