虚拟机栈OOM绝大多数由线程数过多引起，栈帧过大通常只触发StackOverflowError，而不是OOM。 很多开发者把两者混为一谈，其实异常类型完全不同,排查方向也正好相反。
虚拟机栈OOM到底指什么？先分清两个异常
Java虚拟机栈是线程私有的内存区域，每个线程启动时，JVM会为它分配一块独立栈内存，大小由-Xss参数控制，栈里存的是栈帧，每个方法调用都会压入一个栈帧,方法返回时弹出。
栈相关异常只有两种：
StackOverflowError：单线程内调用深度超过栈容量,栈帧放不下了。OutOfMemoryError: unable to create new native thread：JVM无法为新线程分配栈内存,本地内存耗尽。
提问中说的“虚拟机栈OOM”，严格对应第二种，栈帧过大或递归过深，抛的是第一种，行业内常把内存溢出统称OOM,但这两个异常在排查时不能混。
HotSpot虚拟机栈不支持运行时动态扩展，栈容量一旦确定，深度超了就抛StackOverflowError，不会因为扩展失败抛OOM，所以栈帧过大几乎不可能直接导致虚拟机栈OOM，业内专家指出,创建线程时无法分配栈内存才是OOM的直接原因。
线程数过多导致OOM的典型场景和排查思路
线程数过多导致OOM，本质是本地内存不够分给每个线程栈，注意，栈内存不在堆里,它吃的是进程的本地内存。
假设进程可用内存3GB，堆占2GB，元空间占300MB，其他本地内存占几百MB，剩下约1GB给线程栈，如果每个线程栈默认1MB，最多也就能创建一千个左右线程，线程数一旦超过这个量，JVM就会报unable to create new native thread。
线上环境线程数设置多少合适？
这个问题没有统一答案,要根据容器内存和单线程栈大小算。
估算公式大致是：
最大线程数 ≈（进程可用内存 - 堆内存 - 元空间 - 其他本地内存）/ 单线程栈大小
比如4GB内存容器，堆设置2GB，元空间256MB，其他本地内存预留500MB，剩下约1.2GB，栈大小默认1MB，理论最多约1200个线程，但实际要留缓冲，多数情况下线上线程数控制在几百以内更安全，线程数超过进程限制，也会触发
unable to create new native thread,即使内存还有剩余。
线程数过多OOM怎么解决？
- 先看进程当前线程数是否接近系统上限。
- 降低
-Xss，比如从1M调到512k或256k，单线程栈变小,同样内存能容纳更多线程。 - 限制线程池最大线程数,避免线程无限增长。
- 排查线程泄漏，用
jstack观察线程总数是否持续上升。 - 高并发场景改用异步非阻塞模型,减少一线程一请求的占用。
栈帧过大导致StackOverflowError的典型场景
栈帧过大或调用过深,最常见场景就是递归。
递归调用过深导致的栈内存溢出怎么排查？
无限递归或深递归会不停压栈，假设栈容量1MB，每层递归栈帧占用几百字节，几千到几万层就会触发StackOverflowError。
日志特征非常明显：
- 异常类型是
java.lang.StackOverflowError - 堆栈顶部大量重复出现同一个方法名
- 报错前通常看不到业务逻辑异常
排查步骤：
- 打开错误日志，找到
StackOverflowError。 - 从堆栈顶部往下看,重复次数最多的方法就是递归入口。
- 检查递归是否有正确的终止条件。
- 终止条件是否永远无法满足，比如传参错误、边界判断反向。
解决方法：
- 递归改循环。
- 限制递归深度，加一个深度计数器,超限抛业务异常。
- 增大
-Xss能延缓问题,但深层递归迟早还会溢出。 - Java没有原生尾递归优化,不要依赖编译器帮你优化。
单个栈帧过大真的会触发OOM吗？
基本不会，栈帧大小在编译期就基本确定，方法里声明几百个局部变量，栈帧会变大，但栈容量不够时还是抛StackOverflowError，HotSpot栈不能动态扩展,所以不存在扩展失败导致OOM的情况。
很多初学者以为方法里new byte[10MB]会占栈空间，其实数组对象在堆里，栈上只存一个8字节引用，所以单个栈帧过大并不可怕,真正危险的是调用深度和线程数量。
线程数过多和栈帧过大对比
| 对比项 | 线程数过多 | 栈帧过大/递归过深 |
|---|---|---|
| 异常类型 | OutOfMemoryError: unable to create new native thread |
StackOverflowError |
| 内存区域 | 本地内存分配失败 | 单线程栈容量不足 |
| 直接原因 | 线程数超过进程内存或系统上限 | 调用深度超-Xss限制 |
| 常见场景 | 高并发线程池、线程泄漏、Tomcat线程数过高 | 无限递归、深度递归 |
| 解决方向 | 限制线程数、降-Xss、异步化 |
递归改循环、加深度限制 |
排查虚拟机栈OOM的实操命令与步骤
先确认异常类型,再决定排查方向。
第一步：确认是哪种异常
应用日志中出现：
OutOfMemoryError: unable to create new native thread→ 线程数过多或本地内存不足StackOverflowError→ 栈深度超限
第二步：查看线程数和系统限制
Linux环境常用命令：
jstack <pid> | grep "^"" | wc -l统计当前Java进程线程数cat /proc/<pid>/status | grep Threads查看线程数ulimit -u查看当前用户最大进程/线程数cat /proc/sys/kernel/threads-max查看系统全局线程上限free -m查看系统内存剩余
如果线程数接近ulimit -u或者系统内存剩余很少,基本就是线程数过多导致。
第三步：计算单线程栈占用
用jinfo -flag ThreadStackSize <pid>查看当前栈大小，单位是KB，再乘以线程数,就能估算线程栈总占用。
第四步：调整参数
- 降低栈：
-Xss512k或-XX:ThreadStackSize=512 - 限制线程：Spring Boot里配置
server.tomcat.max-threads=200，线程池设置合理核心数和最大数 - 调整堆内存时留足本地内存，不要把容器内存全给
-Xmx
常见误区：把StackOverflowError当OOM去调堆内存
很多开发者看到栈溢出或内存异常，第一反应是调大-Xmx堆内存，结果堆内存越大，本地内存留给线程栈的空间越小，线程数反而更少,问题更严重。
堆内存和栈内存是两块独立区域：
- 堆存对象，由
-Xmx控制 - 栈存方法调用和局部变量，由
-Xss控制
java虚拟机栈默认大小是多少？
默认值随JDK版本和操作系统变化，Linux x64下HotSpot常见默认值是1MB,自己机器上可以这样查看：
java -XX:+PrintFlagsFinal -version | grep ThreadStackSize
不同JDK发行版、不同容器镜像可能不同，排查时先确认实际值,不要拿网上文章的数字直接套。
虚拟机栈OOM主要看异常类型。unable to create new native thread是线程数过多，要限制线程数、降低栈大小。StackOverflowError是栈帧过大或递归过深，要改代码逻辑，两者处理方式完全相反,先分清类型再动手。
虚拟机栈OOM和StackOverflowError有什么区别？
虚拟机栈OOM通常指创建新线程时本地内存不足，报OutOfMemoryError: unable to create new native thread，与线程数和系统内存直接相关，StackOverflowError是单线程栈容量不足，调用深度超过-Xss限制,与递归深度和单帧大小相关。
线程数过多导致OOM怎么定位是哪个线程池造成的？
先用jstack <pid> > thread.txt导出线程栈，统计线程名前缀出现的次数，例如grep "pool-" thread.txt | sort | uniq -c | sort -nr，数量异常的线程池会排在前面,再结合代码中的线程池参数找到对应配置。
线上环境怎么设置Xss避免虚拟机栈内存溢出？
先查看当前默认栈大小，再根据业务方法调用深度做压测，高并发应用可以适当调小-Xss到256k或512k，降低单线程内存占用，从而创建更多线程，调小后要回归测试，确认正常业务调用不会触发StackOverflowError，对于深度递归场景，调大-Xss只能暂时缓解,根本方案还是消除递归。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/642257.html
