A discussion of the maximum number of threads supported by the Java virtual machine

McGovernTheory asked the question on StackOverflow:

How many threads does the Java virtual machine support? Related to virtual machine developers? What about the operating system? Are there other factors?

Eddie's answer:

It depends on the CPU you're using, the operating system, what other processes are doing, the version of Java you're using, and other factors. I've seen a Windows server with over 6500 threads before it went down. Of course, most threads do nothing. Once you have about 6500 threads on a machine (in Java), the machine starts to break down and become unstable.

In my experience, the number of threads held by the JVM is positively correlated with the performance of the machine itself.

Of course, you have to have enough native memory and allocate enough memory for Java so that each thread can have a stack (the virtual stack) and do whatever it wants. Any machine with a modern CPU (AMD or Intel's latest generation) and 1-2g of memory (depending on the operating system) can easily support a Java virtual machine with thousands of threads.

If you need a more accurate answer, it's best to do the pressure test yourself.

Answer by Charlie Martin:

There are many parameters (which you can set). Each has its own runtime parameters for a particular virtual machine. (maximum number of threads) depends partly on the operating system: what does the underlying operating system support for threads? What restrictions are imposed? Is the virtual machine using native operating system threads or red or green threads?

Operating system support is another issue. If you write a Java program like this:

class DieLikeADog {
      public static void main(String[] argv){
          for(;;){
             new Thread(new SomeRunaable).start();
          }
      }
 }

(don't complain about the syntax details, this is just the beginning) then of course you want to have hundreds or thousands of threads running. However, the cost of creating a thread is relatively large, and the overhead of scheduling becomes prominent. Whether these threads can do anything useful is uncertain.

Updated version

All right, I can't wait! Here's my little test program with a touch of polish:

public class DieLikeADog {
    private static Object s = new Object();
    private static int count = 0;
    public static void main(String[] argv){
        for(;;){
            new Thread(new Runnable(){
                    public void run(){
                        synchronized(s){
                            count += 1;
                            System.err.println("New thread #"+count);
                        }
                        for(;;){
                            try {
                                Thread.sleep(1000);
                            } catch (Exception e){
                                System.err.println(e);
                            }
                        }
                    }
                }).start();
        }
    }
}

On Intel's OS/X 10.5.6 system, the output of Java 5 is as follows:

New thread #2547
New thread #2548
New thread #2549
Can't create thread: 5
New thread #2550
Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread
        at java.lang.Thread.start0(Native Method)
        at java.lang.Thread.start(Thread.java:592)
        at DieLikeADog.main(DieLikeADog.java:6)

Benjismith's answer:

After reading Charlie Martin's response, I wondered if the size of the heap would make a difference in the number of threads created, and I was stunned by the result: on Vista Home Premium SP1, using JDK 1.6.0_11, set the heap size from 2M to 1024M to execute Charlie's test program. For example: to create 2M heap memory, I used the virtual machine parameter: -xms2m -xmx2m.

Here are my test results:

2 mb --> 5744 threads
4 mb --> 5743 threads
8 mb --> 5735 threads
12 mb --> 5724 threads
16 mb --> 5712 threads
24 mb --> 5687 threads
32 mb --> 5662 threads
48 mb --> 5610 threads
64 mb --> 5561 threads
96 mb --> 5457 threads
128 mb --> 5357 threads
192 mb --> 5190 threads
256 mb --> 5014 threads
384 mb --> 4606 threads
512 mb --> 4202 threads
768 mb --> 3388 threads
1024 mb --> 2583 threads

So, the size of the heap really matters. However, the heap size is inversely proportional to the maximum number of threads.
This is weird!

Neil Coffey's answer:

The absolute maximum number of threads is the user address space of the process divided by the size of the thread stack. Therefore, in the case of 32-bit Windows, the user address space per process is 2G, and if the size of each thread stack is 128K, there will be 16384(=2*1024* 1024/128) threads at most. In fact, on an XP system, I found that I could start about 13,000 threads.

Then, I think, your question is essentially: (a) can you effectively manage a lot of threads in your code without letting them do something that's obviously stupid (e.g., have them wait on the same object and then be called notifyAll()...) , (b) whether the operating system can effectively manage these many threads. Basically, if (a) the answer is yes, (b) the answer is yes.

Coincidentally, you can set the size of the Thread stack in the constructor of a Thread, but you don't need or should confuse this with a vm parameter.