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

一、JVM（JDK）最大线程数

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

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

        /proc/sys/kernel/pid_max

        /proc/sys/kernel/thread-max

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

        /proc/sys/vm/max_map_count

将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

测试结果：

◆ 不考虑系统限制

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

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

◆ 结合系统限制

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

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

发现线程数量在达到32279以后，不再增长。查了一下，32位Linux系统可创建的最大pid数是32678，这个数值可以通过/proc/sys/kernel/pid_max来做修改（修改方法同threads-max），但是在32系统下这个值只能改小，无法更大。在threads-max一定的情况下，修改pid_max对应的测试结果如下：

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

总结：

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

1、模拟问题:

首先我们通过下面这个测试程序 来认识这个问题：
运行的环境 （有必要说明一下，不同环境会有不同的结果）：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)

2、分析问题：

这个异常问题本质原因是我们创建了太多的线程，而能创建的线程数是有限制的，导致了异常的发生。能创建的线程数的具体计算公式如下： 
(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 
完全和公式一致。 

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

二、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"// 指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理

三、Linux最大线程数

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

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

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

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

2、进程最大线程数

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

3、用户最大进程数

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

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

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
不需要重启，保存后立刻生效，重启项目终于好了