JVM可支持的最大线程数(转)

摘自:http://sesame.iteye.com/blog/622670

工作中碰到过这个问题好几次了,觉得有必要总结一下,所以有了这篇文章,这篇文章分为三个部分:认识问题、分析问题、解决问题。

一、认识问题:

首先我们通过下面这个 测试程序 来认识这个问题:
运行的环境 (有必要说明一下,不同环境会有不同的结果):32位 Windows XP,Sun JDK 1.6.0_18, eclipse 3.4,
测试程序:

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  减小单个线程的栈大小

四、其他:

在java应用中,有时候会出现这样的错误:OutOfMemoryError: unable to create new native thread.这种怪事是因为JVM已经被系统分配了大量的内存(比如1.5G),并且它至少要占用可用内存的一半。有人发现,在线程个数很多的情况下,你分配给JVM的内存越多,那么,上述错误发生的可能性就越大。

每一个32位的进程最多可以使用2G的可用内存,因为另外2G被操作系统保留。这里假设使用1.5G给JVM,那么还余下500M可用内存。这500M内存中的一部分必须用于系统dll的加载,那么真正剩下的也许只有400M,现在关键的地方出现了:当你使用Java创建一个线程,在JVM的内存里也会创建一个Thread对象,但是同时也会在操作系统里创建一个真正的物理线程(参考JVM规范),操作系统会在余下的400兆内存里创建这个物理线程,而不是在JVM的1500M的内存堆里创建。在jdk1.4里头,默认的栈大小是256KB,但是在jdk1.5里头,默认的栈大小为1M每线程,因此,在余下400M的可用内存里边我们最多也只能创建400个可用线程。

这样结论就出来了,要想创建更多的线程,你必须减少分配给JVM的最大内存。还有一种做法是让JVM宿主在你的JNI代码里边。

给出一个有关能够创建线程的最大个数的估算公式:

(MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) = Number of threads

对于jdk1.5而言,假设操作系统保留120M内存:
1.5GB JVM: (2GB-1.5Gb-120MB)/(1MB) = ~380 threads
1.0GB JVM: (2GB-1.0Gb-120MB)/(1MB) = ~880 threads

对于栈大小为256KB的jdk1.4而言,
1.5GB allocated to JVM: ~1520 threads
1.0GB allocated to JVM: ~3520 threads

http://blog.csdn.net/xyls12345/article/details/26482387

 

时间: 2024-08-02 07:27:50

JVM可支持的最大线程数(转)的相关文章

JVM可创建的最大线程数

限制该值的因素: 线程堆栈大小-->进程的最大内存-->操作系统位数   linux线程   查看默认的线程栈大小 ulimit -a   调整栈大小 ulimit -s   是否存在硬限制, /proc/sys/kernel/threads-max是否为硬限制? cat   /proc/sys/kernel/threads-max: ? echo   12000   >   /proc/sys/kernel/thread_max      JVM线程   JVM线程堆栈  应用程序中的

Java虚拟机最多支持多少个线程的探讨_java

McGovernTheory在StackOverflow提了这样一个问题: Java虚拟机最多支持多少个线程?跟虚拟机开发商有关么?跟操作系统呢?还有其他的因素吗? Eddie的回答: 这取决于你使用的CPU,操作系统,其他进程正在做的事情,你使用的Java的版本,还有其他的因素.我曾经见过一台Windows服务器在宕机之前有超过6500个线程.当然,大多数线程什么事情也没有做.一旦一台机器上有差不多6500个线程(Java里面),机器就会开始出问题,并变得不稳定. 以我的经验来看,JVM容纳的

知识点查缺补漏贴03:单机最大进程数,线程数和Socket连接数

前言: 参加Unix/Linux相关高级研发职位时,是否经常会被文档,单机允许最大进程数.线程数和Socket连接数,而你却感到束手无措呢?本文给你一个最为详细的答案. 一.最大进程数 运行Linux ulimit -a指令,我们可以看到:max user processes =1024 运行结构如下图所示: [root@localhost ~]# ulimit unlimited [root@localhost ~]# ulimit -a core file size (blocks, -c)

你真的了解:IIS连接数、IIS并发连接数、IIS最大并发工作线程数、应用程序池的队列长度、应用程序池的最大工作进程数 吗?

原文:你真的了解:IIS连接数.IIS并发连接数.IIS最大并发工作线程数.应用程序池的队列长度.应用程序池的最大工作进程数 吗? IIS连接数   一般购买过虚拟主机的朋友都熟悉购买时,会限制IIS连接数,这边先从普通不懂代码用户角度理解IIS连接数 顾名思义即为IIS服务器可以同时容纳客户请求的最高连接数,准确的说应该叫"IIS限制连接数" 这边客户请求的连接内容包括: 1.网站html请求,html中的图片资源,html中的脚本资源,其他需要连接下载的资源等等,任何一个资源的请求

并发工具类(三)控制并发线程数的Semaphore

简介 Semaphore(信号量)是用来控制同时访问特定资源的线程数量,它通过协调各个线程,以保证合理的使用公共资源.很多年以来,我都觉得从字面上很难理解Semaphore所表达的含义,只能把它比作是控制流量的红绿灯,比如XX马路要限制流量,只允许同时有一百辆车在这条路上行使,其他的都必须在路口等待,所以前一百辆车会看到绿灯,可以开进这条马路,后面的车会看到红灯,不能驶入XX马路,但是如果前一百辆中有五辆车已经离开了XX马路,那么后面就允许有5辆车驶入马路,这个例子里说的车就是线程,驶入马路就表

JVM Bug:多个线程持有一把锁

JVM线程dump Bug描述 在JAVA语言中,当同步块(Synchronized)被多个线程并发访问时,JVM中会采用基于互斥实现的重量级锁.JVM最多只允许一个线程持有这把锁,如果其它线程想要获得这把锁就必须处于等待状态,也就是说在同步块被并发访问时,最多只会有一个处于RUNNABLE状态的线程持有某把锁,而另外的线程因为竞争不到这把锁而都处于BLOCKED状态.然而有些时候我们会发现处于BLOCKED状态的线程,它的最上面那一帧在打印其正在等待的锁对象时,居然也会出现-locked的信息

C#限制并发线程数例程

按自己的想法实现的C#版本的限制并发线程数的例程,给有需要的读者 using System; using System.Collections.Generic; using System.Text; using System.Threading; namespace WZDM.Test { /// <summary> /// 限制并发线程数例程 /// </summary> public class TestThread { int _currentThreads = 0; int

线程通信-Java socket通信 使用jconsole监控发现线程数不断增加

问题描述 Java socket通信 使用jconsole监控发现线程数不断增加 Java socket 使用线程通信,作为接收方每接收一个交易信息,使用jsonsole监控线程发现线程数量增加22个左右,经生产环境运行结果,当已启动线程总数达到2600多时 tomcat出现类似于假死的状况,不再接收任何交易信息.目前正在使用系统定时任务每天定时重启(每日交易量在70-80左右),求大手帮我分析下,现在附上图片和部分代码.jsonsole监控图:部分代码;public class SimpleS

Dubbo线程模型(结合Linux线程数限制配置的实战经验分享)

Dubbo官方文档: 用户指南 >> 示例 >> 线程模型 配置标签: <dubbo:provider/> <dubbo:protocol/> 实战经验分享(属用性能调优): Linux用户线程数限制导致的java.lang.OutOfMemoryError: unable to create new native thread 异常 # vi /etc/security/limits.d/90-nproc.conf # Default limit for