What is the benefit of ThreadGroup in java over creating separate threads?

Many methods like stop(), resume(), su开发者_如何学Cspend() etc are deprecated.

So is it useful to create threads using ThreadGroup?

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.

Don't use ThreadGroup for new code. Use the Executor stuff in java.util.concurrent instead.

Somewhat complimentary to the answer provided (6 years ago or so). But, while the Concurrency API provides a lot of constructs, the ThreadGroup might still be useful to use. It provides the following functionality:

1. Logical organisation of your threads (for diagnostic purposes).
2. You can interrupt() all the threads in the group. (Interrupting is perfectly fine, unlike suspend(), resume() and stop()).
3. You can set the maximum priority of the threads in the group. (not sure how widely useful is that, but there you have it).
4. Sets the ThreadGroup as a daemon. (So all new threads added to it will be daemon threads).
5. It allows you to override its uncaughtExceptionHandler so that if one of the threads in the group throws an Exception, you have a callback to handle it.
6. It provides you some extra tools such as getting the list of threads, how many active ones you have etc. Useful when having a group of worker threads, or some thread pool of some kind.

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

Great answer for @skaffman. I want to add one more advantage:

Thread groups helps manipulating all the threads which are defined in this at once.