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></pid>能看到线程栈快照，如果某线程栈帧数 >5000，基本就是栈问题；jstat -gc <pid></pid>更适合查堆压力
递归改循环时，哪些局部变量必须手动“栈化”
把递归转成显式循环，不能只拆掉函数调用，还得模拟栈行为——尤其是那些随递归深度变化的变量。
- 原始递归中的参数（如
node,level,sum）必须放进自定义栈（如Deque<integer></integer>或对象封装） - 不要用全局变量或静态变量暂存中间状态，否则多线程或嵌套调用会互相污染
- 注意变量作用域：递归里每个栈帧有独立副本，而循环里你要主动 new 对象或 push 新值
- 示例：二叉树中序遍历递归版用
inorder(node.left)→ 循环版需先stack.push(node)，再node = node.left，直到为空才 pop 处理
局部变量多大才会显著推高栈消耗
不是变量数量，而是**每个栈帧里所有局部变量 + 方法元数据的总大小**决定风险。尤其警惕大数组、长字符串、或对象引用频繁创建的场景。
立即学习“Java免费学习笔记（深入）”；
- 基本类型（
int,boolean）栈上只占固定字节（4/1 字节），影响极小 - 对象引用本身只占 4 或 8 字节（取决于是否开启压缩指针），但若你在递归里 new
byte[1024]，那每个栈帧就额外扛 1KB 堆内存——而栈帧本身还得记录这个引用，间接增加 GC 压力 - 避免在递归方法里声明大数组：比如
int[] buffer = new int[10000]放在方法内，每层都 new，实际内存压力远超栈本身 - HotSpot 对“空递归”（无局部变量、无参数）优化较好，但只要涉及对象创建或数组分配，栈帧膨胀速度会陡增
