我知道当前使用Executors而不是ThreadGroup的做法:
通常首选的方式来处理线程
从线程中捕获异常等...
然而,ThreadGroup本身的固有缺陷是什么(我听过那个类的含糊不清的批评)?
谢谢你的回答.
PS.这似乎没有回答这个问题.
这在Effective Java 2nd Ed中有解释.,第73项.
线程组最初被设想为用于隔离小程序的机制以用于安全目的.他们从未真正履行过这一承诺,他们的安全重要性已经降低到甚至在Java安全模型的标准工作中都没有提及[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 theenumerate
method, which takes as a parameter an array large enough to hold all the active threads. TheactiveCount
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 theenumerate
method. If the thread count has increased and the array is too small, theenumerate
method silently ignores any threads for which there is no room in the array.列出线程组子组的API同样存在缺陷.虽然这些问题可以通过添加新方法来解决,但它们没有,因为没有实际需要:线程组已经过时了.
在1.5版之前,只有
ThreadGroup
API 提供了一小段功能:ThreadGroup.uncaughtException
当线程抛出未捕获的异常时,该方法是获得控制权的唯一方法.例如,此功能可用于将堆栈跟踪定向到特定于应用程序的日志.作为释放1.5,然而,相同的功能是可用Thread
的setUncaughtExceptionHandler
方法.总而言之,线程组在提供有用功能方面没有提供太多功能,并且它们提供的大部分功能都是有缺陷的.线程组最好被视为不成功的实验,您应该忽略它们的存在.如果设计一个处理逻辑线程组的类,则应该使用线程池执行程序(第68项).