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

简介: 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这个方法。


1.jpg


从上面代码里首先要大家关注下最后的那个 if 判断 if (native_thread->osthread() == NULL),如果 osthread 为空,那将会抛出大家比较熟悉的 unable to create new native thread OOM 异常,因此 osthread 为空非常关键,后面会看到什么情况下osthread会为空。


另外大家应该注意到了native_thread = new JavaThread(&thread_entry, sz),在这里才会真正创建一个线程。


2.jpg

上面代码里的os::create_thread(this, thr_type, stack_sz)会通过pthread_create来创建线程,而 Linux 下对应的实现如下:


3.jpg

4.jpg

5.jpg


如果在 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_create


stack_size


pthread_create 的实现在 glibc 里,


6.jpg

上面我主要想说的一段代码是int err = ALLOCATE_STACK (iattr, &pd),顾名思义就是分配线程栈,简单来说就是根据 iattr 里指定的 stackSize,通过 mmap 分配一块内存出来给线程作为栈使。


那我们来说说 stackSize,这个大家应该都明白,线程要执行,要有一些栈空间,试想一下,如果分配栈的时候内存不够了,是不是创建肯定失败?而 stackSize 在 JVM 下是可以通过 -Xss 指定的,当然如果没有指定也有默认的值,下面是 JDK6 之后(含)默认值的情况。


Linux Kernel 里的 clone


如果栈分配成功,那接下来就要创建线程了,大概逻辑如下

7.jpg

而create_thread其实是调用的系统调用clone

8.jpg

系统调用这块就切入到了 Linux Kernel 里


clone 系统调用最终会调用do_fork方法,接下来通过剖解这个方法来分析 Kernel 里还存在哪些因素。


max_user_processes

9.jpg

先看这么一段,这里其实就是判断用户的进程数有多少,大家知道在linux下,进程和线程其数据结构都是一样的,因此这里说的进程数可以理解为轻量级线程数,而这个最大值是可以通过ulimit -u可以查到的,所以如果当前用户起的线程数超过了这个限制,那肯定是不会创建线程成功的,可以通过ulimit -u value来修改这个值


max_map_count


在这个过程中不乏有 mallo c的操作,底层是通过系统调用 brk 来实现的,或者上面提到的栈是通过 mmap 来分配的,不管是 malloc 还是 mmap,在底层都会有类似的判断。

10.jpg

如果进程被分配的内存段超过sysctl_max_map_count就会失败,而这个值在 linux 下对应/proc/sys/vm/max_map_count,默认值是 65530,可以通过修改上面的文件来改变这个阈值


max_threads


还存在max_threads的限制,代码如下:

11.jpg

如果要修改或者查看可以通过/proc/sys/kernel/threads-max来操作, 这个值是受到物理内存的限制,在fork_init的时候就计算好了。


12.jpg

pid_max


pid 也存在限制

13.jpg

alloc_pid的定义如下

14.jpg

alloc_pidmap中会判断pid_max,而这个值的定义如下

15.jpg

这个值可以通过 /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 的源码研读时间有限,不一定总结完整,大家可以补充。

相关文章
|
3月前
|
监控 算法 Java
Java虚拟机(JVM)的垃圾回收机制深度解析####
本文深入探讨了Java虚拟机(JVM)的垃圾回收机制,旨在揭示其背后的工作原理与优化策略。我们将从垃圾回收的基本概念入手,逐步剖析标记-清除、复制算法、标记-整理等主流垃圾回收算法的原理与实现细节。通过对比不同算法的优缺点及适用场景,为开发者提供优化Java应用性能与内存管理的实践指南。 ####
|
16天前
|
并行计算 安全 Java
Python GIL(全局解释器锁)机制对多线程性能影响的深度分析
在Python开发中,GIL(全局解释器锁)一直备受关注。本文基于CPython解释器,探讨GIL的技术本质及其对程序性能的影响。GIL确保同一时刻只有一个线程执行代码,以保护内存管理的安全性,但也限制了多线程并行计算的效率。文章分析了GIL的必要性、局限性,并介绍了多进程、异步编程等替代方案。尽管Python 3.13计划移除GIL,但该特性至少要到2028年才会默认禁用,因此理解GIL仍至关重要。
83 16
Python GIL(全局解释器锁)机制对多线程性能影响的深度分析
|
2月前
|
监控 算法 Java
Java虚拟机(JVM)垃圾回收机制深度剖析与优化策略####
本文作为一篇技术性文章,深入探讨了Java虚拟机(JVM)中垃圾回收的工作原理,详细分析了标记-清除、复制算法、标记-压缩及分代收集等主流垃圾回收算法的特点和适用场景。通过实际案例,展示了不同GC(Garbage Collector)算法在应用中的表现差异,并针对大型应用提出了一系列优化策略,包括选择合适的GC算法、调整堆内存大小、并行与并发GC调优等,旨在帮助开发者更好地理解和优化Java应用的性能。 ####
71 0
|
4月前
|
存储 NoSQL Redis
Redis 新版本引入多线程的利弊分析
【10月更文挑战第16天】Redis 新版本引入多线程是一个具有挑战性和机遇的改变。虽然多线程带来了一些潜在的问题和挑战,但也为 Redis 提供了进一步提升性能和扩展能力的可能性。在实际应用中,我们需要根据具体的需求和场景,综合评估多线程的利弊,谨慎地选择和使用 Redis 的新版本。同时,Redis 开发者也需要不断努力,优化和完善多线程机制,以提供更加稳定、高效和可靠的 Redis 服务。
107 1
|
4月前
线程CPU异常定位分析
【10月更文挑战第3天】 开发过程中会出现一些CPU异常升高的问题,想要定位到具体的位置就需要一系列的分析,记录一些分析手段。
112 0
|
1月前
|
存储 监控 算法
Java JVM 面试题
Java JVM(虚拟机)相关基础面试题
|
2月前
|
存储 监控 算法
深入探索Java虚拟机(JVM)的内存管理机制
本文旨在为读者提供对Java虚拟机(JVM)内存管理机制的深入理解。通过详细解析JVM的内存结构、垃圾回收算法以及性能优化策略,本文不仅揭示了Java程序高效运行背后的原理,还为开发者提供了优化应用程序性能的实用技巧。不同于常规摘要仅概述文章大意,本文摘要将简要介绍JVM内存管理的关键点,为读者提供一个清晰的学习路线图。
|
2月前
|
调度 开发者
核心概念解析:进程与线程的对比分析
在操作系统和计算机编程领域,进程和线程是两个基本而核心的概念。它们是程序执行和资源管理的基础,但它们之间存在显著的差异。本文将深入探讨进程与线程的区别,并分析它们在现代软件开发中的应用和重要性。
82 4
|
2月前
|
存储 监控 算法
Java虚拟机(JVM)垃圾回收机制深度解析与优化策略####
本文旨在深入探讨Java虚拟机(JVM)的垃圾回收机制,揭示其工作原理、常见算法及参数调优方法。通过剖析垃圾回收的生命周期、内存区域划分以及GC日志分析,为开发者提供一套实用的JVM垃圾回收优化指南,助力提升Java应用的性能与稳定性。 ####
|
3月前
|
机器学习/深度学习 监控 算法
Java虚拟机(JVM)的垃圾回收机制深度剖析####
本文深入探讨Java虚拟机(JVM)的垃圾回收机制,揭示其工作原理、常见算法、性能调优策略及未来趋势。通过实例解析,为开发者提供优化Java应用性能的思路与方法。 ####
76 1