引言 

这两天在用多线程ThreadPoolExecutor解决问题的时候,突发奇想的了解一下jvm到底最多能创建多少线程,因为在遇到高并发业务场景的时候,必须使用多线程来应付问题,正所谓兵来将挡,水来土掩,业务请求来自然就是线程干活了.了解一下影响jvm创建线程的因素对后续jvm调优,高并发问题的解决多多少会有点帮助吧,,哪怕一点.

 JVM 体系结构

           要想了解jvm对线程的影响,首先得简单了解一下jvm的体系结构,这里直接上图:

 

 

 

 

 

 

 

 

 

                      

            jvm的基本结构图

上图是从网上直接扒下来的,其实都差不多,简单介绍一下;

(1) 程序计数器：

这玩意又叫PC寄存器, 程序计数器是线程私有的内存，JVM多线程是通过线程轮流切换并分配处理器执行时间的方式实现的，当线程切换后需要恢复到正确的执行位置(处理器)时，就是通过程序计数器来实现的。此内存区域是唯一 一个在JVM规范中没有规定任何OutOfMemoryError情况的区域。

(2) Java虚拟机栈：

Java虚拟机栈也是线程私有的，它的生命周期与线程相同，Java虚拟机栈为JVM执行的Java方法(字节码)服务。每个Java方法在执行时都会创建一个栈帧，用于存储局部变量表、操作数栈、动态链表、方法出口等信息。

局部变量表存放的是基本数据类型，对象引用和returnAddress类型。也就是说基本数据类型直接在栈中分配空间；局部变量（在方法或者代码块中定义的变量）也在栈中分配空间，当方法执行完毕后该空间会被JVM回收；引用数据类型，即我们new创建的对象引用，JVM会在栈空间给这个引用分配一个地址空间（门牌号），在堆空间给该对象分配一个空间（家），栈空间的地址引用指向堆空间的对象（通过门牌号找到家）。在这个区域，JVM规范规定了两个异常状况：

a.如果线程请求的栈深度大于JVM所允许的深度，将抛出StackOverflowError异常；

b.如果虚拟机栈可以动态扩容(大部分JVM都可以动态扩容),如果扩展时无法申请到足够的内存，就会抛出OutOfMemoryError异常。

 (3) 本地方法栈：

和Java虚拟机栈作用相似，只是本地方法栈为JVM使用到的Native(本地)方法服务，它也会抛出StackOverflowError和OutOfMemoryError异常

(4) Java堆：

JVM内存中最大的一块，是所有线程共享的区域，在JVM启动时创建，唯一目的就是用来存储对象实例的，也被称为GC堆，因为这是垃圾收集器

管理的主要区域。Java堆还可分为：新生代和老年代，其中新生代还可再分为：Eden：From Survivor：To Survivor = 8:1:1,废话少说,直接上图:

    

 

 

 

 

 

上图结构很明显的给我们展示了,影响jvm内存空间的几个参数,简单介绍下:

-Xmax:表示堆内存的最大值,默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时，JVM会减少堆直到 -Xms的最小限制

-Xms:表示堆内存的初始大小,默认(MinHeapFreeRatio参数可以调整)空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制.

-Xss: 表示虚拟机栈中的线程栈空间大小,JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K.更具应用的线程所需内存大小进行,这玩意将会直接影响线程的数量,接下来会继续探讨.

-XX:MaxNewSize:表示新生代最大空间

-XX:NewSize:表示新生代初始空间大小

-XX:MaxPermSize(jdk8以后改成了MaxMetaspaceSize) 表示永久代(元空间)空间大小

-XX:PermSize(jdk8以后改成了MetaspaceSize)表示永久代(元空间)初始空间大小

JVM线程影响因素

    我们在使用ThreadPoolExcutor(jdk8建议使用此方法来创建多线程)创建多线程的时候,考虑到实际的业务场景以及服务器的实际使用情况,创建线程的过程中多多少少会带来如下常见问题:

    (1) 线程的创建和销毁,会带来系统开销.如果给每个任务都去启动一个线程处理,那么势必造成内存以及cpu等资源的开销

    (2) 无限制的启动过多线程,带来最明显的效果就是内存使用猛增,CPU调度高居不下,过多的线程占用了超多的内存,以及其他内部资源,导致jvm的GC压力增大,CPU调度不及时,如果线程数量超过了底层OS可处理的数量,直接影响到整个系统的性能

因此,jvm能够创建的线程总数,除了系统分配给jvm的内部参数以外,平台本身的资源情况也会影响到线程的总数,也即底层操作系统对线程做了限制.

我们先来验证一下jvm参数,在不考虑底层OS对线程的限制情况下,所能创建的最大线程数是多少,这里直接贴一下我写的代码段,大家可以直接拿下来运行:

代码中的statckSize可以自定义,也可以直接修改-Xss来定义

  public class Test { private int depth ; private void recur(){ this.depth++; recur(); } private void getStackDepth(){ try { recur(); }catch (Throwable t ){ System.out.println("得到的栈最大深度为\t"+this.depth); t.printStackTrace(); } } public static void main(String[] args) { long stackSize = Long.parseLong(args[0]) ; for (int i=1;i<Integer.MAX_VALUE;i++){ try { int tmp = i ; MyThreadFactory.getInstance(tmp,stackSize).newThread(() ->{ try { Field field = Thread.class.getDeclaredField("stackSize"); field.setAccessible(true); long stackSize1 = field.getLong(Thread.currentThread()); System.out.println("线程栈内存大小"+stackSize1+"\t当前OS默认栈内存大小为"+stackSize/1024+"\t"+Thread.currentThread().getName()+"started..."); Thread.sleep(Long.MAX_VALUE); } catch (Exception e) { throw new RuntimeException(); } }).start(); }catch (Throwable ex ){ System.out.println("支持的最大线程数为\t"+i); ex.printStackTrace(); break; } } } private static class MyThreadFactory implements ThreadFactory { private static int num ; private static long stackSize ; private static final AtomicInteger poolAtomic = new AtomicInteger(1); private static final AtomicInteger threadAtomic = new AtomicInteger(1); private ThreadGroup threadGroup ; private static MyThreadFactory myThreadFactory ; private String threadName ; public MyThreadFactory(){ SecurityManager securityManager = System.getSecurityManager() ; threadGroup = securityManager==null?Thread.currentThread().getThreadGroup():securityManager.getThreadGroup(); threadName = "pool-"+poolAtomic.getAndIncrement()+"-thread-"; } public static MyThreadFactory getInstance(int i,long size ){ myThreadFactory = new MyThreadFactory() ; num = i ; stackSize=size; return myThreadFactory ; } @Override public Thread newThread(Runnable r) { Thread thread = new Thread(threadGroup,r,threadName+num,stackSize); if(thread.isDaemon()){ thread.setDaemon(false); } if(thread.getPriority() != Thread.NORM_PRIORITY){ thread.setPriority(Thread.NORM_PRIORITY); } return thread; } } }

为了便于监测执行情况,我将源码发布在了VMware虚拟机上(直接使用本机物理机也行,如果不怕被搞死的话),通过cm的方式直接执行,查看结果.

不考虑硬件资源

验证 java -Xmx512m -Xms512m -Xss228k com/inspur/x1/office/utils/Test 0 > 1.log   

执行完毕,发现出现unable to create new native  thread 的错误日志 ,看一下1.log日志,发现开启的最大线程数为:27643 

验证  java -Xmx1024m -Xms1024m -Xss228k com/inspur/x1/office/utils/Test 0 > 2.log   

执行完毕,发现出现unable to create new native  thread 的错误日志 ,看一下2.log日志,发现开启的最大线程数为:27639

验证 java -Xmx2048m -Xms2048m -Xss228k com/inspur/x1/office/utils/Test 0 > 3.log   

执行完毕,发现出现unable to create new native  thread 的错误日志 ,看一下3.log日志,发现开启的最大线程数为:18728 

验证  java -Xmx512m -Xms512m -Xss2048k com/inspur/x1/office/utils/Test 0 > 4.log  

执行完毕,发现出现unable to create new native  thread 的错误日志,并且内存全部被吃掉,free区变成了0 ,看一下4.log日志,发现开启的最大线程数为:24910

验证  java -Xmx512m -Xms512m com/inspur/x1/office/utils/Test 2097152 > 5.log  

 

执行完毕,发现出现unable to create new native  thread 的错误日志,并且内存全部被吃掉,free区变成了0 ,看一下5.log日志,发现开启的最大线程数为:27638

说明一下:

上述资源在执行的时候,无论将Xms Xmx 以及Xss 设置多大,在内存足够的情况下,可创建的最大线程数永远不会超过27834,因为这是硬件决定的

考虑硬件资源

如果我想让线程数达到100000量级,需要修改如下几个系统资源参数

1) /proc/sys/kernel/pid_max 

此参数定义了OS最大能支持的进程数, 与用户态不同，对于Linux内核而言，进程和线程之间的区别并不大，线程也不过是共享内存空间的进程。每个线程都是一个轻量级进程(Light Weight Process),都有自己的唯一PID(或许叫TID更合适一些)和一个TGID(Thread group ID),TGID是启动整个进程的thread的PID.\

执行命令 ps -fL 

图中LWP表示轻量级的进程,当启动多个线程的时候,LWP值会增加,一直增加到OS所能支持的最大值为止

2) /proc/sys/kernel/thread-max

此参数限制了OS所能支持的线程最大值,默认值为如下图所示

3) /proc/sys/vm/max_map_count 

定义程序运行的时候,在内存共享区域建立的VMA(虚拟内存区域),描述的是程序在分配内存空间的时候,会创建该区域,因此,值越大,分配的进程VMA越多,

这个值直接影响进程拥有的VMA的数量,拥有的越多,进程将会越多,也越占内存,进而导致系统报出内存不足的异常,默认值为如下图所示

4) max_user_process 当前用户允许的最大进程数,默认值如下图,正好是thread-max的一半,(两者具体的联系,目前没搞清楚,后续再研究)

如果想客服硬件资源的限制,在现有资源的基础上,得到100000并发请求,需要如下配置:

1) 设置 thread-max 为100000

2) 设置 max_map_count 为100000

3) 设置 max_user_process 为unlimited 

执行  java -Xmx512m -Xms512m com/inspur/x1/office/utils/Test 2097152 > 6.log

  

看到执行完毕之后,发现线程数量猛增到接近50000的数量,将max_map_count 值设定成200000试试

线程总数飘上来了,接近100000并发,由于内存资源被其他进程占据了一部分,已经很接近目标了,,

执行以下 jstat -gc 进程id,看看当前堆内存的生存情况,发现eden区与survivor区的内存基本全用上了

并且内存已经全部占满了,这就是max-map-count的作用

 

总结

jvm可创建的最大线程数,最根本的是受到OS底层资源的限制,而线程数可分配的数量取决于Xms Xmx 以及Xss参数的配置,但上限不会超过OS硬件支持的总数,硬件资源受到thread-max,max_user_process以及max_map_count的限制,总结成一个公式就是:

最大可用线程数=(OS最大进程内存-JVM内存-系统保留内存)/单个线程栈空间大小

举个例子:

对于栈大小为512KB(即stackSize=512K Xss256k)的jdk1.8而言(抛开硬件资源限制):
1GB allocated to JVM: ~ 大概20000 - 23000 threads
2GB allocated to JVM: ~ 大概 150000 - 18000 threads

可以看到,分给heap的内存越小,理论上得到的线程数就越多,反之越少

   ok,以上是本人亲测总结的影响jvm创建线程受到的影响因素,有不正确的地方欢迎批评指正!