估算jvm进程的最大线程数

结论

结论1 Number of threads = (MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize)
能创建的线程数 = (一个进程的最大内存 - JVM内存 - 保留的操作系统内存) / 线程栈的大小

结论2由公式可知 JVM内存越多,线程栈越大,能创建的线程越少,越容易 OutOfMemoryError
「自」 OutOfMemoryError: unable to create new native thread.

结论3、 如果程序确实需要大量的线程,现有的设置不能达到要求,那么可以通过修改MaxProcessMemoryJVMMemoryThreadStackSize来增加能创建的线程数。
MaxProcessMemory: 改用64位操作系统
JVMMemory: 减少JVMMemory的分配
ThreadStackSize: 减小单个线程的栈大小

结论4、如果程序中有bug,导致创建大量不需要的线程或者线程没有及时回收,那么必须解决这个bug,修改参数是不能解决问题的。

在这里插入图片描述

验证

1. 运行的环境 (不同环境会有不同的结果)

1、32位 Windows XP
2、Sun JDK1.6.0_18
3、eclipse3.4

2. 测试代码

import java.util.concurrent.CountDownLatch;
public class Jvm4_Xss_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) {
				e.printStackTrace();
			}
	}
}

3. 测试结果

# 这个异常问题本质原因是我们创建了太多的线程,而能创建的线程数是有限制的,导致了异常的发生

i = 5602
Exception in thread "main" java.lang.OutOfMemoryError:
unable to create new native thread
atjava.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:597)
at TestNativeOutOfMemoryError.main(TestNativeOutOfMemoryError.java:20)

4. 结果分析

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不能很精确)

在这里插入图片描述

参考

java进程 jvm 线程数量_jvm最大线程数

<think>好的,我现在需要解决用户提到的关于NMT(Native Memory Tracking)中线程栈内存不准确的问题。用户希望找到解决方案。首先,我需要回顾一下NMT的基本知识以及线程栈内存的相关内容。 根据引用[3],NMT可以用来分析泄漏的堆外内存的来源。线程堆栈属于堆外内存的一部分,属于RSS内存区域的一部分,如引用[1]所述。但用户指出,NMT报告的线程栈内存与实际不符,这可能是什么原因呢? 首先,我应该考虑NMT本身的限制。Java的NMT工具可能无法完全跟踪所有本地内存的使用情况,尤其是当线程栈由操作系统直接管理时。例如,某些JVM实现可能不会将线程栈的分配详细报告给NMT,或者存在统计上的误差。 其次,线程栈的大小可以通过JVM参数设置,比如-Xss参数。如果用户设置的栈大小与实际操作系统分配的有所差异,可能导致NMT显示的数据不准确。比如,虽然设置了-Xss1m,但操作系统可能会以页为单位分配内存,导致实际使用量稍大。 另外,可能存在其他因素干扰,比如glibc的内存分配策略(如使用mmap或brk),或者线程创建和销毁时的动态变化,导致NMT无法实时跟踪。例如,线程销毁后,其栈内存可能不会立即释放回操作系统,导致NMT统计残留。 接下来,解决方案方面,引用[3]提到使用NMT结合jcmd来分析内存泄漏的位置。但对于线程栈的不准确问题,可能需要更细致的排查。用户可能需要手动计算线程数和栈大小的乘积,与实际报告的数值对比,以发现差异。 另外,引用[5]提到容器环境中JVM的内存管理问题,特别是旧版本可能无法正确感知容器限制。如果用户的环境是容器化的,可能需要检查JVM版本是否支持UseContainerSupport参数,确保线程栈大小的计算基于正确的内存限制。 可能的步骤包括: 1. 确认JVM版本是否支持UseContainerSupport,并确保其启用,以正确计算栈内存。 2. 使用系统工具(如pmap或/proc/<pid>/smaps)直接查看进程的内存映射,对比NMT报告的数据。 3. 调整-Xss参数,观察NMT报告的变化是否合理。 4. 结合操作系统级别的内存监控工具,如top或ps,查看RES的使用情况,与NMT数据交叉验证。 同时,引用[4]提到使用jmap来dump内存,但这对堆内内存更有效。对于堆外内存,可能需要其他工具,如jemalloc的统计信息或Valgrind等,但这些可能不在用户的问题范围内。 用户可能需要检查是否有第三方库或JNI代码创建了未被NMT跟踪的线程,导致栈内存统计遗漏。例如,某些本地库可能直接调用pthread_create,绕过JVM的管理,从而NMT无法追踪这些线程的栈内存。 总结可能的解决方案: - 升级JVM到较新版本,确保容器环境下正确配置。 - 结合系统工具手动分析线程栈内存。 - 检查是否有非JVM管理的线程存在。 - 调整线程栈大小参数并监控变化。</think>### 解决NMT中线程栈内存不准确的问题 #### 1. 确认JVM版本与容器支持 若运行在容器环境中,确保使用**JDK 8u191+**或**JDK 11+**,并启用`-XX:+UseContainerSupport`参数(默认已开启)。旧版本JVM可能错误地将主机内存而非容器限制作为计算基准,导致线程栈大小估算偏差[^5]。 #### 2. 手动计算线程栈内存总量 通过以下公式估算理论线程栈内存占用: $$ \text{总线程栈内存} = \text{活跃线程数} \times \text{单个线程栈大小(-Xss参数值)} $$ 使用命令获取活跃线程数: ```bash jstack <pid> | grep 'java.lang.Thread.State' | wc -l ``` 对比NMT报告的`Thread`部分数值。若差异较大,可能说明存在未统计的线程或参数配置问题。 #### 3. 使用系统工具直接验证 通过`pmap`或`/proc/<pid>/smaps`查看实际内存映射: ```bash pmap -x <pid> | grep 'stack' ``` 统计所有线程栈区域(通常标记为`[stack]`或`[stack:<tid>]`)的RSS值,与NMT数据对比。若系统工具显示更高,可能因操作系统以内存页为单位分配,或存在未释放的残留栈内存[^1]。 #### 4. 调整线程栈大小参数 尝试显式设置`-Xss`(如`-Xss256k`),观察NMT报告是否同步变化。若未变化,可能JVM实现存在限制,或线程栈实际分配受系统策略影响(如最小栈大小限制)。 #### 5. 检查非JVM管理的线程 若存在JNI调用或第三方库(如本地库通过`pthread_create`创建线程),这些线程的栈内存不会被NMT追踪。可通过`pstree -p <pid>`或`ps -T -p <pid>`查看所有线程,确认是否存在非Java线程[^2]。 #### 6. 启用详细NMT日志 启动时添加参数: ```bash -XX:NativeMemoryTracking=detail -XX:+UnlockDiagnosticVMOptions -XX:+PrintNMTStatistics ``` JVM退出时输出详细内存统计,检查`Thread`部分是否包含异常值。 #### 7. 结合第三方工具分析 使用`gdb`或`jemalloc`分析内存分配: ```bash gdb -p <pid> (gdb) info proc mappings ``` 或通过`strace`跟踪`mmap`调用,观察线程栈的实际分配大小。 #### 示例验证步骤 1. 设置`-Xss256k`并启动应用。 2. 使用`jcmd <pid> VM.native_memory summary`获取NMT报告。 3. 通过`pmap`计算实际线程栈内存总和。 4. 若NMT数值明显低于pmap结果,可能存在未统计的本地线程或操作系统分配差异。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值