关于JVM(JDK)，Tomcat，Linux的最大线程数问题

时间 2019-11-19

标签关于 jvm jdk tomcat linux 最大线程问题栏目 Java 繁體版

原文原文链接

1、JVM（JDK）最大线程数

JVM最大建立线程数量由JVM堆内存大小、线程的Stack内存大小、系统最大可建立线程数（Java线程的实现是基于底层系统的线程机制来实现的，Windows下_beginthreadex，Linux下pthread_create）三个方面影响。具体以下：java

-Xms 最小堆内存
-Xmx 最大堆内存
-Xss 设置每一个线程的堆栈大小。JDK5.0之后每一个线程堆栈大小为1M
操做系统限制 系统最大可开线程数，主要受如下几个参数影响linux

/proc/sys/kernel/pid_max数据库

/proc/sys/kernel/thread-maxvim

max_user_process（ulimit -u）在64位Linux系统（CentOS 6， 3G内存）下测试，发现还有一个参数是会限制线程数量：max user process（可经过ulimit –a查看，默认值1024，经过ulimit –u能够修改此值），这个值在上面的32位Ubuntu测试环境下并没有限制windows

/proc/sys/vm/max_map_counttomcat

将threads-max，pid_max，max user process，这三个参数值都修改为100000，-Xms，-Xmx尽可能小（128m，64m），-Xss尽可能小（64位下最小104k，可取值128k）。事先预测在这样的测试环境下，线程数量就只会受限于测试环境的内存大小（3G），但是实际的测试结果是线程数量在达到32K（32768，建立的数量最多的时候大概是33000左右）左右时JVM是抛出警告：Attempt to allocate stack guard pages failed，而后出现OutOfMemoryError没法建立本地线程。查看内存后发现还有不少空闲，因此应该不是内存容量的缘由。/proc/sys/vm/max_map_count的数量翻倍，从65536变为131072，建立的线程总数量达到65000+，电脑基本要卡死（3G内存）…服务器

简单查了下这个参数的做用，在[8]中的描述以下：多线程

“This file contains the maximum number of memory map areas a process may have. Memory map areas are used as a side-effect of calling malloc, directly by mmap and mprotect, and also when loading shared libraries.架构

While most applications need less than a thousand maps, certain programs, particularly malloc debuggers, may consume lots of them, e.g., up to one or two maps per allocation.并发

The default value is 65536.”

操做系统最大线程数限制

32位Linux系统可建立的最大pid数是32678，这个数值能够经过/proc/sys/kernel/pid_max来作修改（修改其值为10000：echo 10000 > /proc/sys/kernel/pid_max），可是在32系统下这个值只能改小，没法改大。

Windows可建立的线程数量比linux可能更少。

在64位Linux系统（CentOS 6）下，还有一个参数会限制线程数量：max user process（可经过ulimit –a查看，默认值1024，经过ulimit –u能够修改此值）

测试程序以下：

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; 
            } 
    } 
}

测试环境：

系统：Ubuntu 10.04 Linux Kernel 2.6 （32位）

内存：2G

JDK：1.7

测试结果：

◆ 不考虑系统限制

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

在建立的线程数量达到31842个时，系统中没法建立任何线程。

由上面的测试结果能够看出增大堆内存（-Xms，-Xmx）会减小可建立的线程数量，增大线程栈内存（-Xss，32位系统中此参数值最小为60K）也会减小可建立的线程数量。

◆ 结合系统限制

线程数量31842的限制是是由系统能够生成的最大线程数量决定的：/proc/sys/kernel/threads-max，可其默认值是32080。修改其值为10000：echo 10000 > /proc/sys/kernel/threads-max，修改后的测试结果以下：

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

这样的话，是否是意味着能够配置尽可能多的线程？再作修改：echo 1000000 > /proc/sys/kernel/threads-max，修改后的测试结果以下：

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

发现线程数量在达到32279之后，再也不增加。查了一下，32位Linux系统可建立的最大pid数是32678，这个数值能够经过/proc/sys/kernel/pid_max来作修改（修改方法同threads-max），可是在32系统下这个值只能改小，没法更大。在threads-max必定的状况下，修改pid_max对应的测试结果以下：

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

在Windows上的状况应该相似，不过相比Linux，Windows上可建立的线程数量可能更少。基于线程模型的服务器总要受限于这个线程数量的限制。

总结：

JVM中能够生成的最大数量由JVM的堆内存大小、Thread的Stack内存大小、系统最大可建立的线程数量（Java线程的实现是基于底层系统的线程机制来实现的，Windows下_beginthreadex，Linux下pthread_create）三个方面影响。具体数量能够根据Java进程能够访问的最大内存（32位系统上通常2G）、堆内存、Thread的Stack内存来估算。

一、模拟问题:

首先咱们经过下面这个测试程序来认识这个问题：
运行的环境（有必要说明一下，不一样环境会有不一样的结果）：32位 Windows XP，Sun JDK 1.6.0_18， eclipse 3.4，
测试程序：

Java代码

import java.util.concurrent.CountDownLatch;  
  
public class TestNativeOutOfMemoryError {  
  
    public static void main(String[] args) {  
  
        for (int i = 0;; i++) {  
            System.out.println("i = " + i);  
            new Thread(new HoldThread()).start();  
        }  
    }  
  
}  
  
class HoldThread extends Thread {  
    CountDownLatch cdl = new CountDownLatch(1);  
  
    public HoldThread() {  
        this.setDaemon(true);  
    }  
  
    public void run() {  
        try {  
            cdl.await();  
        } catch (InterruptedException e) {  
        }  
    }  
}

不指定任何JVM参数，eclipse中直接运行输出，看到了这位朋友了吧：
i = 5602

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:597)
    at TestNativeOutOfMemoryError.main(TestNativeOutOfMemoryError.java:20)

二、分析问题：

这个异常问题本质缘由是咱们建立了太多的线程，而能建立的线程数是有限制的，致使了异常的发生。能建立的线程数的具体计算公式以下：
(MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) = Number of threads
MaxProcessMemory 指的是一个进程的最大内存
JVMMemory         JVM内存
ReservedOsMemory 保留的操做系统内存
ThreadStackSize      线程栈的大小

在java语言里，当你建立一个线程的时候，虚拟机会在JVM内存建立一个Thread对象同时建立一个操做系统线程，而这个系统线程的内存用的不是JVMMemory，而是系统中剩下的内存(MaxProcessMemory - JVMMemory - ReservedOsMemory)。

结合上面例子咱们来对公式说明一下：
MaxProcessMemory 在32位的 windows下是 2G
JVMMemory   eclipse默认启动的程序内存是64M
ReservedOsMemory 通常是130M左右
ThreadStackSize 32位 JDK 1.6默认的stacksize 325K左右
公式以下：
(2*1024*1024-64*1024-130*1024)/325 = 5841
公式计算所得5841，和实践5602基本一致（有误差是由于ReservedOsMemory不能很精确）

由公式得出结论：你给JVM内存越多，那么你能建立的线程越少，越容易发生java.lang.OutOfMemoryError: unable to create new native thread。

咦，有点背咱们的常理，恩，让咱们来验证一下,依旧使用上面的测试程序，加上下面的JVM参数，测试结果以下：
ThreadStackSize      JVMMemory                    能建立的线程数
默认的325K             -Xms1024m -Xmx1024m    i = 2655
默认的325K             -Xms1224m -Xmx1224m    i = 2072
默认的325K             -Xms1324m -Xmx1324m    i = 1753
默认的325K             -Xms1424m -Xmx1424m    i = 1435
-Xss1024k -Xms1424m -Xmx1424m i = 452
彻底和公式一致。

三、解决问题：
1，若是程序中有bug，致使建立大量不须要的线程或者线程没有及时回收，那么必须解决这个bug，修改参数是不能解决问题的。
2，若是程序确实须要大量的线程，现有的设置不能达到要求，那么能够经过修改MaxProcessMemory，JVMMemory，ThreadStackSize这三个因素，来增长能建立的线程数：
a, MaxProcessMemory 使用64位操做系统
b, JVMMemory   减小JVMMemory的分配
c, ThreadStackSize 减少单个线程的栈大小

2、Tomcat最大线程数

当一个进程有 500 个线程在跑的话，那性能已是很低很低了。Tomcat 默认配置的最大请求数是 150，也就是说同时支持 150 个并发，固然了，也能够将其改大。
当某个应用拥有 250 个以上并发的时候，应考虑应用服务器的集群。
具体能承载多少并发，须要看硬件的配置，CPU 越多性能越高，分配给 JVM 的内存越多性能也就越高，但也会加剧 GC 的负担。
操做系统对于进程中的线程数有必定的限制：
Windows 每一个进程中的线程数不容许超过 2000
Linux 每一个进程中的线程数不容许超过 1000
另外，在 Java 中每开启一个线程须要耗用 1MB 的 JVM 内存空间用于做为线程栈之用。
Tomcat的最大并发数是能够配置的，实际运用中，最大并发数与硬件性能和CPU数量都有很大关系的。更好的硬件，更多的处理器都会使Tomcat支持更多的并发。
Tomcat 默认的 HTTP 实现是采用阻塞式的 Socket 通讯，每一个请求都须要建立一个线程处理。这种模式下的并发量受到线程数的限制，但对于 Tomcat 来讲几乎没有 BUG 存在了。
Tomcat 还能够配置 NIO 方式的 Socket 通讯，在性能上高于阻塞式的，每一个请求也不须要建立一个线程进行处理，并发能力比前者高。但没有阻塞式的成熟。
这个并发能力还与应用的逻辑密切相关，若是逻辑很复杂须要大量的计算，那并发能力势必会降低。若是每一个请求都含有不少的数据库操做，那么对于数据库的性能也是很是高的。
对于单台数据库服务器来讲，容许客户端的链接数量是有限制的。
并发能力问题涉及整个系统架构和业务逻辑。
系统环境不一样，Tomcat版本不一样、JDK版本不一样、以及修改的设定参数不一样。并发量的差别仍是满大的。
maxThreads="1000" 最大并发数
minSpareThreads="100"///初始化时建立的线程数
maxSpareThreads="500"///一旦建立的线程超过这个值，Tomcat就会关闭再也不须要的socket线程。
acceptCount="700"// 指定当全部可使用的处理请求的线程数都被使用时，能够放处处理队列中的请求数，超过这个数的请求将不予处理

3、Linux最大线程数

研发环境上的Linux项目启动报错：Caused by: java.lang.OutOfMemoryError: unable to create new native thread

开始觉得是内存不足致使没法建立线程，把jvm的-Xms，-Xmx的2个参数都加大一倍：-Xms2048m -Xmx2048m。把-Xss参数调小，仍是启动失败。应该是系统方面的限制了，这台机器上搞了100个过tomcat进程，还有很多其余软件，东西比较多且杂。确认过机器的内存仍是足够的，先排查系统参数，以后再清理垃圾资源了。

一、系统可生成最大线程数

cat /proc/sys/kernel/threads-max
这个值很大，tomcat进程的所有线程数确定没有超过它，若是实际线程数比它大可改大（实际多是代码问题，开启了太多线程）。

二、进程最大线程数

ps -eLf | grep 项目名 | wc -l 查看单个项目线程数，启动失败的这个项目线程数通常在600左右
cat /proc/sys/vm/max_map_count
65530
这个值没有问题，jvm的启动参数为-Dconfig.server.maxThreads=3000，也没有问题

三、用户最大进程数

ulimit -a
其中max user processes就是表示用户的最大进程数，个人这个值很大，进程数也没有超过它。若是超过的话，能够修改最大进程数的配置
vi /etc/security/limits.d/90-nproc.conf
* soft nproc 1024
root soft nproc unlimited
上面能够看除了root用户外的全部用户均限制为1024，所以经过能够注释此行或者将值改大，保存后修改马上生效
#* soft nproc 1024
root soft nproc unlimited

四、整个系统已用的线程或进程数

cat /proc/sys/kernel/pid_max 该值是32678（32位Linux系统可建立的最大pid数是32678），查询当前整个系统已用的线程或进程数：pstree -p | wc -l，结果比32678稍小，问题就在这了 vim /proc/sys/kernel/pid_max,改成65535保存退出的时候报错以下 /proc/sys/kernel/pid_max E667 Fsync failed 改为下面方式便可： echo "65535" > /proc/sys/kernel/pid_max 不须要重启，保存后马上生效，重启项目终于好了