为什么ThreadGroup受到批评？

我知道使用Executors而不是ThreadGroup的当前做法：

• 通常首选的方式来处理线程
• 从线程等中捕获exception……

但是， ThreadGroup本身的固有缺陷是什么（我听过那个类的含糊不清的批评）？

谢谢你的回答。

PS。 这似乎没有回答这个问题。

Answer 1

这在Effective Java 2nd Ed中有解释。 ，第73项。

线程组最初被设想为用于隔离小程序的机制以用于安全目的。 他们从来没有真正履行过这个承诺，他们的安全重要性已经降低到甚至在Java安全模型的标准工作中都没有提到[Gong03]。

[…]具有讽刺意味的是，从线程安全的角度来看， ThreadGroup API很弱。 要获取线程组中活动线程的列表，必须调用enumerate方法，该方法将一个足以容纳所有活动线程的数组作为参数。 activeCount方法返回线程组中活动线程的数量，但是一旦分配了数组并将其传递给enumerate方法，就无法保证此计数仍然准确。 如果线程数增加且数组太小，则enumerate方法将静默忽略数组中没有空间的任何线程。

列出线程组子组的API同样存在缺陷。 虽然这些问题可以通过添加新方法来解决，但它们没有，因为没有实际需要： 线程组已经过时了 。

在1.5版之前，只有ThreadGroup API可以使用一小段function：当线程抛出未捕获的exception时， ThreadGroup.uncaughtException方法是获得控制权的唯一方法。 例如，此function可用于将堆栈跟踪定向到特定于应用程序的日志。 但是，从1.5版开始， Thread的setUncaughtExceptionHandler方法可以使用相同的function。

总而言之，线程组不会提供有用的function，并且它们提供的大部分function都是有缺陷的。 线程组最好被视为不成功的实验，您应该忽略它们的存在。 如果设计一个处理逻辑线程组的类，则应该使用线程池执行程序（第68项）。