为什么ThreadGroup被批评？

Question

我知道使用执行程序而不是ThreadGroup的当前做法：

• 通常首选的处理线程的方法
• 从线程等捕获异常…

但是，这样 的ThreadGroup 固有的 缺陷是 什么（我听过对该类的模糊批评）？

感谢您的回答。

PS。这似乎无法回答这个问题。

Answer 1

这在《有效的Java第二版》中进行了解释。，项目73。

最初将线程组设想为一种出于安全目的隔离小程序的机制。他们从来没有真正兑现过这个诺言，其安全重要性已经下降到在Java安全模型[Gong03]的标准工作中甚至没有提到的程度。

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

列出线程组子组的API同样存在缺陷。尽管可以通过添加新方法来解决这些问题，但由于没有真正的需要，因此没有解决这些问题： 线程组已过时 。

在1.5版之前，只有ThreadGroupAPI 提供一小部分功能：ThreadGroup.uncaughtException
当线程引发未捕获的异常时，该方法是获得控制权的唯一方法。例如，此功能可用于将堆栈跟踪定向到特定于应用程序的日志。但是，从1.5版开始，Thread的setUncaughtExceptionHandler方法可以使用相同的功能。

总而言之，线程组没有提供有用功能的方式，它们提供的许多功能都有缺陷。最好将线程组视为不成功的实验，您应该完全忽略它们的存在。如果设计一个处理逻辑线程组的类，则可能应该使用线程池执行程序（项目68）。