4. 栈内存溢出（StackOverflow）排查：线程栈深度分析

栈内存溢出，说白了就是你的线程“栈”这个空间被撑爆了。JVM为每个线程分配了一块固定大小的栈空间，用来存放方法调用的局部变量、操作数栈、动态链接和方法出口等信息。一旦调用链太深，栈帧太多，这块空间就不够用了，JVM就会抛出java.lang.StackOverflowError。

我个人在早期做递归算法优化时，就经常跟这个错误打交道。你想想看，一个递归函数少写一个终止条件，程序跑起来没几秒就挂了，挺让人头疼的。这一章我们就深挖一下，这个错误到底是怎么来的，以及如何通过调整-XX:ThreadStackSize来应对它。

4.1 递归调用导致栈溢出的经典案例

先看一个最简单的例子。这是一个典型的“无限递归”（其实是有终止条件但深度太大）：

public class StackOverflowDemo {
    private static int depth = 0;

    public static void recursiveMethod() {
        depth++;
        // 模拟一个没有终止条件的递归
        recursiveMethod();
    }

    public static void main(String[] args) {
        try {
            recursiveMethod();
        } catch (StackOverflowError e) {
            System.out.println("栈溢出发生在深度: " + depth);
        }
    }
}

运行这段代码，你会看到类似下面的输出：

栈溢出发生在深度: 11410

这个数字不是固定的，它取决于你的JVM默认栈大小、方法内的局部变量数量、以及操作数栈的复杂度。我遇到过一个真实案例，一个简单的递归方法在默认配置下能跑到2万层才溢出，但另一个带了大量局部变量的方法，连5000层都撑不到就挂了。

4.2 线程栈深度分析：到底是怎么“爆”的？

为什么同样的递归深度，有的能过有的不能过？这就要说说栈帧的构成。每个方法调用都会在栈上分配一个栈帧，栈帧里包含：

• 局部变量表：存储方法参数和方法内定义的局部变量。变量越多，栈帧越大。
• 操作数栈：进行算术运算、方法调用传递参数时使用的临时存储区。
• 动态链接：指向运行时常量池中该方法的引用。
• 方法出口：正常返回或异常返回时的返回地址。

假设你的方法里定义了10个局部变量，每个变量占4个字节（int类型），光局部变量表就至少40个字节。加上操作数栈、方法出口等信息，一个栈帧可能轻松达到几百字节。如果默认线程栈大小是1MB，那最多只能放下几千个栈帧。一旦递归深度超过这个阈值，栈就爆了。

我个人的排查习惯是，先用jstack把线程堆栈抓出来看看：

jstack <pid> > thread_dump.txt

然后在dump里搜索“StackOverflowError”或者查看线程的调用栈信息。你会看到类似这样的内容：

"main" #1 prio=5 os_prio=0 tid=0x00007f8a4400a800 nid=0x2b3b in Object.wait() [0x00007f8a4e8f2000]
   java.lang.Thread.State: RUNNABLE
        at StackOverflowDemo.recursiveMethod(StackOverflowDemo.java:6)
        at StackOverflowDemo.recursiveMethod(StackOverflowDemo.java:6)
        at StackOverflowDemo.recursiveMethod(StackOverflowDemo.java:6)
        ...  (重复几万行)

这就是栈溢出的铁证。看到这种重复的调用链，你基本可以断定是递归或深层循环调用导致的问题。

4.3 如何通过-XX:ThreadStackSize调整栈大小

知道了问题根源，解决思路就清晰了。要么优化算法减少递归深度（比如改成迭代），要么增加线程栈的大小。今天我们主要讲后者。

JVM参数-XX:ThreadStackSize用来设置每个线程的栈大小，单位是字节，但通常我们用k或m来指定。语法很简单：

-XX:ThreadStackSize=512k
# 或者
-Xss512k

这两个参数其实是等价的，-Xss是简写形式。我个人习惯用-XX:ThreadStackSize，因为更直观一些。

来看看调整前后的对比：

从表格里能看出，栈大小和递归深度基本是线性关系。但要注意，并不是栈越大越好。每个线程都会占用一块栈内存，如果你开了几百个线程，每个线程2MB，那光栈内存就要吃掉几百MB甚至上GB。生产环境要综合考虑线程数和可用内存。

4.4 什么时候该调大，什么时候该调小？

其实大多数情况下，我们不应该去调整栈大小，而是应该优化代码。递归深度过大往往意味着算法设计有问题，比如没有处理好分治策略，或者递归里嵌套了太多的逻辑。

不过也有例外。我遇到过这样几个场景：

• 深度优先遍历：比如解析一个深度超过1万层的XML/JSON文档，递归遍历不可避免。这时候调大栈大小是合理的临时方案。
• 嵌入式系统或低内存环境：有时候需要反过来调小栈大小。我记得一个IoT项目，设备内存只有64MB，JVM只能分到32MB，那每个线程栈设成128k都算多了，必须精简代码。
• 单元测试中的递归算法：比如写一个尾递归优化的阶乘函数，测试深度经常跑到几万层，这时可以在测试脚本里单独加大栈大小。

调大的时候，我建议每次增加256k-512k，测试通过后不要再往上加。调小的时候，从默认值往下压，压到刚好能稳定运行即可。

4.5 实战排查流程

我一般按照这个步骤来排查栈溢出问题：

1. 抓堆栈：运行jstack <pid>，看是否有明显的重复调用链。
2. 分析源码：定位到报错的方法，检查是否存在无终止条件的递归、或者递归分支过多。
3. 计算理论深度：粗略估算一个方法栈帧的大小（可以写个小程序打印出来），结合默认栈大小算出理论最大深度。
4. 尝试调大：如果确定是递归深度合理但不够用，就逐步加大-XX:ThreadStackSize。
5. 验证稳定性：加大后跑一遍压力测试，确认不会引起OOM或性能下降。

下面这张图是我自己整理的一个排查逻辑，你可以参考：

4.6 实际参数配置示例

假如你确定要调整栈大小，可以在JVM启动参数里这样写：

java -XX:ThreadStackSize=2m -jar myapplication.jar

或者用-Xss：

java -Xss2m -jar myapplication.jar

如果你用的是Spring Boot，可以在application.properties里加：

# Spring Boot 2.x 及更高版本
spring.application.jvm-args=-XX:ThreadStackSize=2m

或者直接在bin/start.sh里改：

JAVA_OPTS="$JAVA_OPTS -XX:ThreadStackSize=2m"
exec java $JAVA_OPTS -jar myapplication.jar

嗯，这里要注意一点：不同操作系统、不同JVM版本，默认的栈大小不一样。Linux x64上的HotSpot JVM默认是1MB，但Windows上可能只有512KB。所以如果你的代码在开发环境（Linux）上好好的，放到生产（Windows）上却栈溢出了，别惊讶，很可能是默认栈大小不一样导致的。

我记得有一次帮同事排查一个很奇怪的问题——他写的递归在本地跑没问题，放到测试服务器就挂了。我让他用java -XX:+PrintFlagsFinal -version查看默认栈大小，果然，本地是1MB，测试服务器只有512KB。最后统一给两个环境都设成1MB，问题解决。

检查默认栈大小的命令是：

java -XX:+PrintFlagsFinal -version | grep -i stack

你会看到类似：

intx ThreadStackSize = 1024   # 单位是KB，所以1024就是1MB

通过这些手段，你可以快速定位并解决栈溢出问题。不过还是那句话，能优化算法就别调参数，这是最稳妥的方式。