JVM源码分析之一个Java进程究竟能创建多少线程

虽然这篇文章的标题打着JVM源码分析的旗号，不过本文不仅仅从JVM源码角度来分析，更多的来自于Linux Kernel的源码分析，今天要说的是JVM里比较常见的一个问题这个问题可能有几种表述•一个Java进程到底能创建多少线程？•到底有哪些因素决定了能创建多少线程？•java.lang.OutOfMemoryError: unable to create new native thread的异常究竟是怎么回事不过我这里先声明下可能不能完全百分百将各种因素都理出来，因为毕竟我不是做Linux Kernel开发的，还有不少细节没有注意到的，我将我能分析到的因素和大家分享一下，如果大家在平时工作中还碰到别的因素，欢迎在文章下面留言，让更多人参与进来讨论从JVM说起线程大家都熟悉，new
Thread().start()即会创建一个线程，这里我首先指出一点new Thread()其实并不会创建一个真正的线程，只有在调用了start方法之后才会创建一个线程，这个大家分析下Java代码就知道了，Thread的构造函数是纯Java代码，start方法会调到一个native方法start0里，而start0其实就是JVM_StartThread这个方法从上面代码里首先要大家关注下最后的那个if判断if (native_thread->osthread() == NULL)，如果osthread为空，那将会抛出大家比较熟悉的unable
to create new native thread OOM异常，因此osthread为空非常关键，后面会看到什么情况下osthread会为空另外大家应该注意到了native_thread = new JavaThread(&thread_entry, sz)，在这里才会真正创建一个线程上面代码里的os::create_thread(this, thr_type, stack_sz)会通过pthread_create来创建线程，而Linux下对应的实现如下：如果在new OSThread的过程中就失败了，那显然osthread为NULL，那再回到上面第一段代码，此时会抛出java.lang.OutOfMemoryError:
unable to create new native thread的异常，而什么情况下new OSThread会失败，比如说内存不够了，而这里的内存其实是C Heap，而非Java Heap，由此可见从JVM的角度来说，影响线程创建的因素包括了Xmx，MaxPermSize，MaxDirectMemorySize，ReservedCodeCacheSize等，因为这些参数会影响剩余的内存另外注意到如果pthread_create执行失败，那通过thread->set_osthread(NULL)会设置空值，这个时候osthread也为NULL，因此也会抛出上面的OOM异常，导致创建线程失败，因此接下来要分析下pthread_create失败的因素glibc中的pthread_createstack_sizepthread_create的实现在glibc里，上面我主要想说的一段代码是int
err = ALLOCATE_STACK (iattr, &pd)，顾名思义就是分配线程栈，简单来说就是根据iattr里指定的stackSize，通过mmap分配一块内存出来给线程作为栈使用那我们来说说stackSize，这个大家应该都明白，线程要执行，要有一些栈空间，试想一下，如果分配栈的时候内存不够了，是不是创建肯定失败？而stackSize在JVM下是可以通过-Xss指定的，当然如果没有指定也有默认的值，下面是JDK6之后(含)默认值的情况估计不少人有一个疑问，栈内存到底属于-Xmx控制的Java Heap里的部分吗，这里明确告诉大家不属于，因此从glibc的这块逻辑来看，JVM里的Xss也是影响线程创建的一个非常重要的因素。Linux
Kernel里的clone如果栈分配成功，那接下来就要创建线程了，大概逻辑如下而create_thread其实是调用的系统调用clone系统调用这块就切入到了Linux Kernel里clone系统调用最终会调用do_fork方法，接下来通过剖解这个方法来分析Kernel里还存在哪些因素max_user_processes先看这么一段，这里其实就是判断用户的进程数有多少，大家知道在linux下，进程和线程其数据结构都是一样的，因此这里说的进程数可以理解为轻量级线程数，而这个最大值是可以通过ulimit -u可以查到的，所以如果当前用户起的线程数超过了这个限制，那肯定是不会创建线程成功的，可以通过ulimit
-u value来修改这个值max_map_count在这个过程中不乏有malloc的操作，底层是通过系统调用brk来实现的，或者上面提到的栈是通过mmap来分配的，不管是malloc还是mmap，在底层都会有类似的判断如果进程被分配的内存段超过sysctl_max_map_count就会失败，而这个值在linux下对应/proc/sys/vm/max_map_count，默认值是65530，可以通过修改上面的文件来改变这个阈值max_threads还存在max_threads的限制，代码如下如果要修改或者查看可以通过/proc/sys/kernel/threads-max来操作，
这个值是受到物理内存的限制，在fork_init的时候就计算好了pid_maxpid也存在限制而alloc_pid的定义如下在alloc_pidmap中会判断pid_max,而这个值的定义如下这个值可以通过/proc/sys/kernel/pid_max来查看或者修改总结通过对JVM，glibc，Linux kernel的源码分析，我们暂时得出了一些影响线程创建的因素，包括•JVM：Xmx，Xss，MaxPermSize，MaxDirectMemorySize，ReservedCodeCacheSize等•Kernel：max_user_processes，max_map_count，max_threads，pid_max等由于对kernel的源码研读时间有限，不一定总结完整，大家可以补充PS：今天正巧我们公司有个专门做性能的同事开通了公众号并写了一篇因为网络抖动导致的性能问题有兴趣的可以扫描二维码关注一下，后续估计也会写不少性能相关的文章本人其他JVM相关文章◦JVM源码分析之System.currentTimeMillis及nanoTime原理详解◦JVM源码分析之String.intern()导致的YGC不断变长◦JVM源码分析之不保证顺序的Class.getMethods◦JVM源码分析之Metaspace解密◦JVM源码分析之临门一脚的OutOfMemoryError完全解读◦JVM源码分析之不可控的堆外内存◦JVM源码分析之jstat工具原理完全解读◦JVM源码分析之JDK8下的僵尸(无法回收)类加载器◦JVM源码分析之栈溢出完全解读◦JVM源码分析之Attach机制实现完全解读◦JVM源码分析之自定义类加载器如何拉长YGC◦JVM源码分析之FinalReference完全解读◦JVM源码分析之javaagent原理完全解读◦JVM源码分析之Object.wait/notify(All)完全解读◦JVM源码分析之堆外内存完全解读◦JVM源码分析之SystemGC完全解读◦JDK8在泛型类型推导上的变化◦YGC前后新生代变大？◦消失的死锁◦进程物理内存远大于Xmx的问题分析◦不可逆的类初始化过程◦JDK的sql设计不合理导致的驱动类初始化死锁问题◦如何定位消耗CPU最多的线程◦Java的时间为何从1970年1月1日开始