There is no hard limit, but typically a JVM will start to buckle somewhere between a few hundred and a few thousand threads, depending on the implementation.
- Green threads emulate "real" threads using an unprivileged code library. They can be less efficient, are usually more prone to thread starvation, and won't make proper use of multi-CPU machines. One operating system thread is mapped to n Java threads.
- Native threads use the operating system's threading support. They are generally pre-emptive, reasonably efficient, and make use of multiple CPUs. But they are dependent on the efficiency of the OS's threading implementation. n operating system threads map to n Java threads.
- A highly tuned server JVM like JRockit combines the two threading types outlined above, mapping n operating system threads to m Java threads (m > n). This allows it to handle thousands of threads without breaking into a sweat.
It is difficult to make sweeping statements about the relative merits of these threading implementations - there are too many variables. For hard information, check out The Volano report, especially the network scalability test (which is primarily governed by threading behaviour).
Last but not least, I'd like to mention v1.4 of the J2SDK, currently in beta, which introduces a new non-blocking I/O architecture (java.nio.*). This allows servers to handle more than one client per thread which should improve scalability a great deal (in a sense it gives you the n:m behaviour of JRockit).
- Peter
[This message has been edited by Peter den Haan (edited October 27, 2001).]