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

标签: Java开发总结 | 发表时间:2017-11-13 03:21 | 作者:
出处:https://my.oschina.net/u/2391658

一、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

测试结果:

◆ 不考虑系统限制

-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内存来估算。

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

相关 [jvm jdk tomcat] 推荐:

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

- - 孟飞阳的博客
一、JVM(JDK)最大线程数. JVM最大创建线程数量由JVM堆内存大小、线程的Stack内存大小、系统最大可创建线程数(Java线程的实现是基于底层系统的线程机制来实现的,Windows下_beginthreadex,Linux下pthread_create)三个方面影响. -Xmx  最大堆内存.

配置tomcat jvm 及cpu查看

- - Java - 编程语言 - ITeye博客
使用tomcat做为java容器,cpu占用偏高的原因,目前公司服务器上面跑的ubuntu环境nginx+tomcat+mysql运行一段时间之后java进程cpu偏高,会出现网站打不开的情况. 一,首先查看tomcat日志,如果有出现OOM错误(内存溢出)可以对应的加大jvm的内存大小. 1,修改tomcat目录下bin目录下的catalina.sh文件,在.

tomcat下jvm参数配置详解

- - 博客园_首页
在解释下面知识之前,一个很重要的知识点必须了解,那就是tomcat本身是不能直接运行在计算机上的,必须依赖硬件基础上的计算机和一个java虚拟机,这也就解释了为什么在安装运行tomcat前必须要安装jvm的原因了. 所以说如果运行一个比较大的应用程序的话,一个性能高的jvm和合适的参数配置对程序的性能影响很大,因为Sun公司和其它一些公司一直在为提高性能而对java虚拟机做一些升级改进.

Tomcat启动:A fatal error has been detected by the Java Runtime Environment(JVM Crash分析及相关资料)

- - CSDN博客推荐文章
2013年1月10号注:. 今天更新代码之后,突然出现一个问题:Tomcat启动时,总是会出现jvm fatal error错误导致tomcat无法正常启动,以下是错误信息:. 在网上搜寻好久,终于找到了类似错误,网上解释归结于:JIT在做编译优化的时候处理时出错,可能是触发了JVM的编译器的BUG导致的.

Sun JDK 1.6内存管理

- 小丑鱼 - 淘宝JAVA中间件团队博客
分为使用篇、调优篇和实现篇三个部分,使用篇为填鸭式,调优篇为pattern式,实现篇为启发式,三个PPT的目标为:. 1.掌握Sun JDK的内存区域的划分;. 2.掌握Sun JDK垃圾收集器的使用方法和触发时机;. 4.掌握一些基本的GC调优的方法;. 5.了解自动内存管理的常见实现方法,以及Sun JDK所做的优化.

JDK自带监控工具

- - ITeye博客
         系统在生产运行过程中最重要的工作莫过于监控与问题的处理,监控是预防问题产生很重要的手段. 在监控过程中可以发现那些模块或进程出现了问题,出现问题后会及时通知问题负责人.         实现监控的手段非常多,有系统级别监控系统,也有监控小工具等等. Java 就已经自带了一些监控工具,可以不借助外部软件的情况下简单、快速查看相应监控信息.

JDK动态代理机制

- - CSDN博客编程语言推荐文章
    代理模式有两种,一种是静态代理,这种方式需要为每一个被代理类写一个代理类,显示比较麻烦. 还一种是动态代理,动态代理实现方式一般有两种,JDK动态代理与CGLIB动态代理,这里说一下对JDK动态代理的理解.     JDK动态代理最核心的就类就是java.lang.reflect.Proxy,可调用Proxy.newInstance(..)生成动态代理.

JAVA之JDK动态代理

- - Java - 编程语言 - ITeye博客
在Java的java.lang.reflect包下提供了一个Proxy类和一个InvocationHandler接口,通过这个类和接口,可以生成JDK动态代理类或动态代理对象. Proxy提供了用于创建动态代理类和代理对象的静态方法,它也是所有动态代理类的父类,如果在程序中为一个或多个接口动态的生成实现类,就可以使用Proxy来创建动态代理类,.

tomcat调优

- - 开源软件 - ITeye博客
1          概述. 本文档主要介绍了Tomcat的性能调优的原理和方法. 可作为公司技术人员为客户Tomcat系统调优的技术指南,也可以提供给客户的技术人员作为他们性能调优的指导手册. 2          调优分类. 由于Tomcat的运行依赖于JVM,从虚拟机的角度我们把Tomcat的调整分为外部环境调优和自身调优两类来描述.

Tomcat 优化

- - 编程语言 - ITeye博客
tomcat默认参数是为开发环境制定,而非适合生产环境,尤其是内存和线程的配置,默认都很低,容易成为性能瓶颈. linux修改TOMCAT_HOME/bin/catalina.sh,在前面加入. windows修改TOMCAT_HOME/bin/catalina.bat,在前面加入. 最大堆内存是1024m,对于现在的硬件还是偏低,实施时,还是按照机器具体硬件配置优化.