为什么ThreadGroup被批评？ [英] Why ThreadGroup is being criticised?

问题描述

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

• 通常首选方法来处理主题


• 从线程捕获异常等...

但是，

$ b

感谢您的回答。

$ b b p PS。 这似乎

解决方案

这在 Effective Java 2nd Ed。，Item 73。

线程组最初被设想为一个机制
为了安全目的隔离applet。他们从来没有真正实现这个
承诺，并且他们的安全重要性已经减少到它们不是
的程度，甚至在Java安全模型[Gong03]的标准工作中提到。

[...]在一个讽刺的转折中， ThreadGroup API从线程安全
的角度来看是弱的。要获取线程组中的活动线程的列表，必须调用
枚举方法，该方法将足够大的数组$ b所有活动线程。 activeCount 方法返回线程组中的活动
线程的数目，但不能保证这个计数仍然是
，一旦数组已分配并传递给枚举方法。如果
的线程计数已增加并且数组太小，枚举方法
默认忽略数组中没有空间的任何线程。

列出线程组的子组的API同样有缺陷。虽然
这些问题可以通过添加新的方法修复，他们
没有，因为没有真正需要：线程组已过时。

在1.5版之前，有一个小功能可用
只有 ThreadGroup API： ThreadGroup.uncaughtException
方法是当线程引发未捕获异常时获得控制的唯一方法。
此功能非常有用，例如，将堆栈跟踪定向到应用程序
特定日志。然而，从版本1.5，相同的功能可用
与线程的 setUncaughtExceptionHandler 方法。 / p>

总而言之，线程组不提供很多有用的功能，
和他们提供的大部分功能是有缺陷的。线程组
最好被视为不成功的实验，你应该忽略它们的
存在。如果你设计一个处理逻辑线程组的类，那么
应该可能使用线程池执行器（Item 68）。

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

• generally preferred way to deal with Threads
• catching exceptions from threads, etc...

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

Thanks for answer.

PS. this does not seem to answer this question.

解决方案

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

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].

[...] 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.

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.

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.

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屋！