这在《有效的Java第二版》中进行了解释。，项目73。
最初将线程组设想为一种出于安全目的隔离小程序的机制。他们从来没有真正兑现过这个诺言，其安全重要性已经下降到在Java安全模型[Gong03]的标准工作中甚至没有提到的程度。
具有讽刺意味的
ThreadGroup是，从线程安全的角度来看，API较弱。要获取线程组中活动线程的列表，必须调用该enumerate方法，该方法将一个足以容纳所有活动线程的数组作为参数。该activeCount方法返回线程组中活动线程的数量，但是不能保证一旦分配了数组并将其传递给该enumerate方法后，此计数仍将是准确的。如果线程数增加并且数组太小，则该enumerate方法将无提示地忽略数组中没有空间的所有线程。列出线程组子组的API同样存在缺陷。尽管可以通过添加新方法来解决这些问题，但由于没有真正的需要，因此没有解决这些问题： 线程组已过时 。
在1.5版之前，只有
ThreadGroupAPI 提供一小部分功能：ThreadGroup.uncaughtException
当线程引发未捕获的异常时，该方法是获得控制权的唯一方法。例如，此功能可用于将堆栈跟踪定向到特定于应用程序的日志。但是，从1.5版开始，Thread的setUncaughtExceptionHandler方法可以使用相同的功能。总而言之，线程组没有提供有用功能的方式，它们提供的许多功能都有缺陷。最好将线程组视为不成功的实验，您应该完全忽略它们的存在。如果设计一个处理逻辑线程组的类，则可能应该使用线程池执行程序（项目68）。
