为什么 ThreadGroup 受到批评? [英] Why ThreadGroup is being criticised?

问题描述

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

I'm aware of current practice of using Executors instead of ThreadGroup:

• 通常首选的处理线程的方式
• 从线程等中捕获异常...

但是，ThreadGroup 固有的缺陷是什么(我听说过对该类的模糊批评)?

However, what are the inherent flaws of ThreadGroup as such (I've heard a vague criticism for that class)?

感谢您的回答.

附注.这个似乎没有来回答这个问题.

PS. this does not seem to answer this question.

推荐答案

这在 Effective Java 第二版，第 73 条.

This is explained in Effective Java 2nd Ed., Item 73.

线程组最初被设想为一种机制出于安全目的隔离小程序.他们从来没有真正实现过这一点承诺，并且他们的安全重要性已经减弱到他们不甚至在 Java 安全模型的标准工作 [Gong03] 中也提到过.

Thread groups were originally envisioned as a mechanism for isolating applets for security purposes. They never really fulfilled this promise, and their security importance has waned to the extent that they aren’t even mentioned in the standard work on the Java security model [Gong03].

[...] 讽刺的是，ThreadGroup API 的线程安全性很弱立场.要获取线程组中活动线程的列表，您必须调用enumerate 方法，它将一个足够大的数组作为参数所有活动线程.activeCount 方法返回活动的数量线程组中的线程，但不能保证这个计数仍然是一旦分配了数组并将其传递给 enumerate 方法，则准确.如果线程数增加，数组太小，enumerate方法静默忽略数组中没有空间的任何线程.

[...] In an ironic twist, the ThreadGroup API is weak from a thread safety standpoint. To get a list of the active threads in a thread group, you must invoke the enumerate method, which takes as a parameter an array large enough to hold all the active threads. The activeCount method returns the number of active threads in a thread group, but there is no guarantee that this count will still be accurate once an array has been allocated and passed to the enumerate method. If the thread count has increased and the array is too small, the enumerate method silently ignores any threads for which there is no room in the array.

列出线程组子组的 API 也存在类似缺陷.尽管这些问题可以通过添加新方法来解决，它们没有，因为没有真正的需要:线程组已经过时.

The API that lists the subgroups of a thread group is similarly flawed. While these problems could have been fixed with the addition of new methods, they haven’t, because there is no real need: thread groups are obsolete.

在发布 1.5 之前，有一小部分功能可用仅使用 ThreadGroup API:ThreadGroup.uncaughtException当线程抛出未捕获的异常时，方法是获得控制权的唯一方法.此功能很有用，例如，将堆栈跟踪定向到应用程序 -具体日志.但是，从 1.5 版开始，可以使用相同的功能使用 Thread 的 setUncaughtExceptionHandler 方法.

Prior to release 1.5, there was one small piece of functionality that was available only with the ThreadGroup API: the ThreadGroup.uncaughtException method was the only way to gain control when a thread threw an uncaught exception. This functionality is useful, for example, to direct stack traces to an application- specific log. As of release 1.5, however, the same functionality is available with Thread’s setUncaughtExceptionHandler method.

总而言之，线程组并没有提供太多有用的功能，他们提供的大部分功能都存在缺陷.线程组最好将其视为不成功的实验，您应该简单地忽略它们存在.如果你设计一个处理逻辑线程组的类，你应该使用线程池执行器(条目 68).

To summarize, thread groups don’t provide much in the way of useful functionality, and much of the functionality they do provide is flawed. Thread groups are best viewed as an unsuccessful experiment, and you should simply ignore their existence. If you design a class that deals with logical groups of threads, you should probably use thread pool executors (Item 68).

这篇关于为什么 ThreadGroup 受到批评?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！