Java栈溢出原因解析：递归与局部变量影响

StackOverflowError 根本原因是 JVM 默认栈空间不足，递归深度超限所致，而非逻辑错误；它发生在线程栈，与堆内存溢出有本质区别。

为什么递归没写错也会报 StackOverflowError

根本原因不是递归逻辑有 bug，而是 JVM 默认栈空间太小，而你的调用深度超出了限制。哪怕每次只压入几个字节的局部变量，几千层递归就可能耗尽默认的 1MB（或更少）栈空间。

• StackOverflowError 是运行时错误，不是异常，无法被 try-catch 捕获并“恢复”
• 常见于深度遍历树、未加终止条件的递归、或隐式递归（如重写了 toString() 又在其中打印自身）
• JVM 参数 -Xss 控制单个线程栈大小，例如 -Xss2m 可缓解，但治标不治本
• 递归中每层方法调用都会保存：参数、局部变量、返回地址、栈帧元数据——哪怕你只声明一个 int，它也占空间

StackOverflowError 和内存溢出（OutOfMemoryError: Java heap space）怎么区分

两者常被混淆，但发生位置和触发机制完全不同：前者发生在**线程栈**，后者发生在**堆内存**。

• 栈溢出通常伴随极深的相同方法重复出现在异常堆栈里（比如几百行都是 compute() 调用自身）
• 堆溢出则堆栈里方法调用层级浅，但对象创建密集，且 GC 频繁失败；JVM 会抛 OutOfMemoryError: Java heap space
• 一个线程栈撑爆不会影响其他线程，但堆溢出是整个 JVM 堆的问题
• 用 jstack <pid> 能看到线程栈快照，如果某线程栈帧数 >5000，基本就是栈问题；jstat -gc <pid> 更适合查堆压力

递归改循环时，哪些局部变量必须手动“栈化”

把递归转成显式循环，不能只拆掉函数调用，还得模拟栈行为——尤其是那些随递归深度变化的变量。

• 原始递归中的参数（如 node, level, sum）必须放进自定义栈（如 Deque<Integer> 或对象封装）
• 不要用全局变量或静态变量暂存中间状态，否则多线程或嵌套调用会互相污染
• 注意变量作用域：递归里每个栈帧有独立副本，而循环里你要主动 new 对象或 push 新值
• 示例：二叉树中序遍历递归版用 inorder(node.left) → 循环版需先 stack.push(node)，再 node = node.left，直到为空才 pop 处理

局部变量多大才会显著推高栈消耗

不是变量数量，而是**每个栈帧里所有局部变量 + 方法元数据的总大小**决定风险。尤其警惕大数组、长字符串、或对象引用频繁创建的场景。

• 基本类型（int, boolean）栈上只占固定字节（4/1 字节），影响极小
• 对象引用本身只占 4 或 8 字节（取决于是否开启压缩指针），但若你在递归里 new byte[1024]，那每个栈帧就额外扛 1KB 堆内存——而栈帧本身还得记录这个引用，间接增加 GC 压力
• 避免在递归方法里声明大数组：比如 int[] buffer = new int[10000] 放在方法内，每层都 new，实际内存压力远超栈本身
• HotSpot 对“空递归”（无局部变量、无参数）优化较好，但只要涉及对象创建或数组分配，栈帧膨胀速度会陡增

事情说清了就结束。真正难调的不是报错那一刻，而是那个“看起来没做啥”的递归——它可能藏在日志打印、JSON 序列化、甚至 Spring 的代理回调里。