A Thread group is (big surprise!) a group of Threads. A Thread group can contain a set of Threads as well as a set of other Thread groups. It's a way of bundling several related threads together and doing certain housekeeping things to all of them, like starting them all with a single method invocation.
There are methods to create a Thread group and add a Thread to it. You can get a reference to your Thread group for later use:
private ThreadGroup mygroup;
mygroup=Thread.currentThread().getThreadGroup();
Thread groups exist because it turned out to be a useful concept in the runtime library. There seemed no reason not to just pass it through to application programmers, as well. The designers of the new java.util.concurrency package suggest that thread groups were never much use, and might be deprecated in future. So avoid them.
Sometimes programmers ask, “How many threads should I have in my program?” Ron Winacott of Sun Canada has done a lot of thread programming, and he compares this question to asking, “How many people can I take in my transport?”
The problem is that so much is left unspecified. What kind of transport is it? Is it a motorbike or a jumbo jet? Are the people children, or 250-pound pro wrestlers like Ric Flair? How many are needed to help get to where you want to go (e.g., driver, radio operator, navigator, tail gunner, nanny, observer)? In other words, what kind of program is it, what's the workload, and on what hardware are you running it?
The bottom line is: Each thread has a default stack size of 400K in the JDK current release. It will also use about 0.5K to hold its internal state, but the stack size is the limiting factor. A 32-bit UNIX process (UNIX is the most capable of all the systems to which Java has been ported) effectively has a 2 GB user address space[3] , so in theory, you could have around 5,000 threads. In practice, you would be limited by CPU availability, swap space, and disk bandwidth before you got up there. In one experiment, I was able to create almost 2,000 threads before my desktop system ground to a halt. That was just to create them; I'm not making any claims about them doing any useful work.
Now, back to the real question. Overall, there is no unique correct answer. How many is “reasonable”? There is only one person who can accurately answer this question and that is the programmer writing the threaded application. The runtime library used to have a comment mentioning 26 threads as being the maximum concurrency that one might reasonably expect. That precision lends spurious plausibility, but it's just a rule of thumb.
The best estimate is “the number of threads needed to perform the task”. If this number is too high for the address space or the CPU power, then you must redesign the tasks (and the number of threads) to use what is available. Use threads to achieve concurrency or to gain overlapping I/O. Do not try to create a new thread for every single method, class, or object in your program.
[3] The kernel has the other 2 GB of the 4 GB that can be addressed using 32 bits.