Many methods like stop(), resume(), suspend() etc are deprecated.
So is it useful to create threads using ThreadGroup?
views:
387answers:
3
+1
A:
The short answer is - no, not really. There's little if any benefit to using one.
To expand on that slightly, if you want to group worker threads together you're much better off using an ExecutorService. If you want to quickly count how many threads in a conceptual group are alive, you still need to check each Thread individually (as ThreadGroup.activeCount() is an estimation, meaning it's not useful if the correctness of your code depends on its output).
I'd go so far as to say that the only thing you'd get from one these days, aside from the semantic compartmentalisation, is that Threads constructed as part of a group will pick up the daemon flag and a sensible name based on their group. And using this as a shortcut for filling in a few primitives in a constructor call (which typically you'd only have to write once anyway, sicne you're probably starting the threads in a loop and/or method call).
So - I really don't see any compelling reason to use one at all. I specifically tried to, a few months back, and failed.
EDIT - I suppose one potential use would be if you're running with a SecurityManager, and want to assert that only threads in the same group can interrupt each other. Even that's pretty borderline, as the default implementation always returns true for a Thread in any non-system thread group. And if you're implementing your own SecurityManager, you've got the possibility to have it make its decision on any other criteria (including the typical technique of storing Threads in collections as they get created).
Andrzej Doyle
2009-10-30 10:57:07
How do you store a `Thread` in a collection as it is created. I can't see how you can tell when a thread is created.
Tom Hawtin - tackline
2009-10-30 11:26:45
The bit where you go `new Thread(...)`. :-) Since a Thread can only be explicitly assigned to a group at construction time, it's reasonable to assume that the OP's code is explicitly creating them. If he's not calling the constructor himself he can't change the thread group anyway.
Andrzej Doyle
2009-10-30 12:09:42
+2
A:
Using ThreadGroup can be a useful diagnostic technique in big application servers with thousands of threads. If your threads are logically grouped together, then when you get a stack trace you can see which group the offending thread was part of (e.g. "Tomcat threads", "MDB threads", "thread pool X", etc), which can be a big help in tracking down and fixing the problem.
skaffman
2009-10-30 11:08:55
I've considered that in the past, and I don't think it gives you anything over just naming the threads appropriately. If you can't modify the thread names however, or you have a tool that monitors thread activity aggregated by group, then that's a different matter.
Andrzej Doyle
2009-10-30 11:13:37
Fair point, but the additional structure can be useful, for example aggregating CPU usage by thread group.
skaffman
2009-10-30 11:17:35
I use them in a very large enterprise application for this particular reason. I could have kept track of them myself but it would have forced me into writing quite a lot of code to manage the contents of my collection when thread finish, dies etc.
Fredrik
2009-10-30 11:20:09
A:
Don't use ThreadGroup for new code. Use the Executor stuff in java.util.concurrent instead.
Greg Mattes
2009-10-30 13:00:54