为什么ThreadGroup会受到批评？

Question

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

• 一般首选的处理线程的方法
• 捕捉线程的异常等等..。

然而， ThreadGroup的固有缺陷是什么(我听到了对该类的模糊批评)？

谢谢你的回答。

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

Answer 1

这一点在有效爪哇第二版。第73项中作了解释。

线程组最初被设想为一种为安全目的隔离小程序的机制。他们从未真正履行过这一承诺，而且他们的安全重要性已经减弱，以至于在Java模型Gong03的标准工作中甚至没有提到他们。 ..。具有讽刺意味的是，从线程安全的角度来看，ThreadGroup API很弱。要获得线程组中的活动线程列表，必须调用enumerate方法，该方法以一个足够大的数组作为参数，足以容纳所有活动线程。activeCount方法返回线程组中的活动线程数，但在分配数组并将其传递给enumerate方法后，无法保证此计数仍将是准确的。如果线程数量增加，且数组太小，则enumerate方法将默认忽略数组中没有空间的任何线程。 列出线程组的子组的API也有类似的缺陷。虽然这些问题可以通过添加新方法来解决，但它们没有解决，因为没有真正的需求：线程组是过时的。 在版本1.5之前，有一小部分功能只能在ThreadGroup API中使用:当线程抛出一个未察觉的异常时，ThreadGroup.uncaughtException方法是获得控制的唯一方法。例如，此功能对于将堆栈跟踪定向到特定于应用程序的日志非常有用。但是，在第1.5版中，Thread的setUncaughtExceptionHandler方法也提供了相同的功能。 总之，线程组并没有提供很多有用的功能，而且它们提供的许多功能都存在缺陷。线程组最好被看作是一个失败的实验，您应该简单地忽略它们的存在。如果设计一个处理逻辑线程组的类，则可能应该使用线程池执行器(项目68)。