jvm supports simple tests for maximum number of threads

Recently, to test the maximum concurrency under Openfire, a large number of threads were needed to simulate the client. I have been wondering how many threads 1 can be opened for an instance of JVM, so I plan to actually test simple google and find out the factors affecting the number of threads as follows:

-Xms	intial java heap size
-Xmx	maximum java heap size
-Xss	the stack size for each thread
系统限制	系统最大可开线程数

The test procedure is as follows: Java code:

import java.util.concurrent.atomic.AtomicInteger;  
  
public class TestThread extends Thread {  
  private static final AtomicInteger count = new AtomicInteger();  
  
  public static void main(String[] args) {  
    while (true)  
      (new TestThread()).start();  
  
  }  
  
  @Override  
  public void run() {  
    System.out.println(count.incrementAndGet());  
  
    while (true)  
      try {  
        Thread.sleep(Integer.MAX_VALUE);  
      } catch (InterruptedException e) {  
        break;  
      }  
  }  
}  

Test environment: System: Ubuntu 10.04 Linux Kernel 2.6 (32-bit)
Memory: 2 G
JDK: 1.7

Test results:
Ø Regardless of system constraints

-Xms	-Xmx	-Xss	结果
1024m	1024m	1024k	1737
1024m	1024m	64k	26077
512m	512m	64k	31842
256m	256m	64k	31842

No threads can be created in the system when the number of threads created reaches 31,842.

From the above test results, it can be seen that increasing heap memory (-ES30en, -ES31en) reduces the number of threads that can be created, while increasing thread stack memory (-ES32en, the minimum value of this parameter in 32-bit systems is 60K) also reduces the number of threads that can be created

Ø Binding system constraint

Thread count limit is 31842 is the maximum number of threads can be generated by the system of decision: / proc/sys/kernel/threads - max, to its default value is 32080. Change the value to 10000: echo 10000 > / proc/sys/kernel/threads - max, modified test results are as follows:

-Xms	-Xmx	-Xss	结果
256m	256m	64k	9761

Does this mean that as many threads as possible can be configured? Further modification: echo 1000000 > / proc/sys/kernel/threads - max, modified test results are as follows:

-Xms	-Xmx	-Xss	结果
256m	256m	64k	32279
128m	128m	64k	32279

Found that the number of threads did not increase after reaching 32,279. Checked 1, 32 Linux system can create the maximum number of pid is 32678, this value can be achieved by/proc sys/kernel/pid_max modifications (modified method with threads - max), but in 32 system under this value can only change a little, not more. Under the condition of ES78en-max1, the corresponding test results of pid_max are modified as follows:

pid_max	-Xms	-Xmx	-Xss	结果
1000	128m	128m	64k	582
10000	128m	128m	64k	9507

The situation should be similar on Windows, although the number of threads that can be created on Windows is probably smaller than on Linux. Servers based on the thread model are always limited by the number of threads.

The maximum amount that can be generated in JVM is influenced by the heap memory size of JVM, the Stack memory size of Thread, and the maximum number of threads that can be created in the system (the implementation of Java threads is based on the threading mechanism of the underlying system, pthread_create under Linux). The amount can be estimated based on the maximum memory available to the Java process (1G on 32-bit systems), heap memory, and Stack memory for Thread.

Preface:

On a 64-bit Linux system (CentOS6, 3G memory), one more parameter was found that would limit the number of threads: maxuserprocess (viewed by ulimit, the default value is 1024, and modified by ulimit, u), which is not unlimited in the above 32-bit Ubuntu test environment.

The three parameter values of threads-ES120en, pid_max and maxuserprocess are modified to 100000, -ES124en, -ES124en and -ES128en as small as possible (128m, 64m) and -ES128en as small as possible (minimum 104k under 64 bits, which can be 128k). Predict in advance in the test environment, number of threads will only be limited to the test environment of memory size (3 G), but the actual test results is the number of threads in 32 K (32768, created the largest number of time is about 33000 or so) about JVM is thrown caution: Attempttoallocatestackguardpagesfailed, then appear OutOfMemoryError unable to create local thread. Looking at the memory reveals that there is a lot of free space, so it should not be the memory capacity. Google this warning has been fruitless, we do not know the reason for the time being, and further study is needed.

2:

Today accidentally found the article [7], immediately tried, indeed as expected the factors affect the number of thread creation, described by the/proc sys/vm/the number of max_map_count doubled, from 65536 to 131072, the total number of threads created 65000 +, computer basic card to death (3) G memory... The function of this parameter is simply checked and described in [8] as follows:

"Thisfilecontainsthemaximumnumberofmemorymapareasaprocessmayhave. Memorymapareasareusedasaside - effectofcallingmalloc directlybymmapandmprotect, andalsowhenloadingsharedlibraries.

Whilemostapplicationsneedlessthanathousandmaps,certainprograms,particularlymallocdebuggers,mayconsumelotsofthem,e.g.,uptooneortwomapsperallocation.

Thedefaultvalueis65536."

OK, this problem has been solved completely. Finally, the factors affecting the number of Java threads are summarized as follows:

Java Virtual machine itself: -Xms, -ES169en, -ES170en;

System restrictions:

/ proc sys/kernel/pid_max,

/ proc/sys/kernel/thread - max,

max_user_process (ulimit-ES193en),

/ proc sys/vm/max_map_count.

conclusion

That's all for this article about jvm's support for simple tests of maximum number of threads, and I hope you found it helpful. Interested friends can continue to refer to other related topics in this site, if there is any deficiency, welcome to comment out.