Java递归抛出StackOverflowError是因为线程栈空间耗尽：每层递归压入栈帧，超过JVM默认栈容量（如1MB）即崩溃，与逻辑正确性无关，常见于树遍历、嵌套JSON解析等场景。
Java递归调用为什么会突然抛出 StackOverflowError
因为每个线程的栈空间是有限的，递归每深入一层就压一个栈帧，深度超过 JVM 默认栈容量（通常 1MB 左右）就会崩。这不是代码写错了，而是资源耗尽——哪怕逻辑完全正确也会挂。
常见错误现象：Exception in thread "main" java.lang.StackOverflowError，堆栈里全是重复的同一方法调用，看不到其他线索。
- 默认栈大小因 JVM 实现和平台而异，OpenJDK 在 64 位 Linux 上通常约 1024KB，但实际能撑多少层递归，取决于每次调用压入的局部变量数量
- 递归函数里声明大数组、长字符串或嵌套对象引用，会显著缩短安全深度
-
-Xss可调栈大小（如-Xss2m），但治标不治本；盲目加大可能挤占堆内存，甚至触发 OOM
怎么估算当前环境的安全递归深度
没法精确算，但可以快速探个底。别靠“理论上能到几千层”，得实测——尤其当你的递归要处理用户输入或配置驱动的层级结构时。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 写一个最简递归函数，只做
i++和递归调用，无参数传递、无返回值 - 用
try-catch捕获StackOverflowError，记录最后一次成功进入的层数 - 在目标运行环境（同 JDK 版本、同
-Xss参数）下跑，比如容器里跑和本地 IDE 跑结果常差一倍
示例：
public static int depth = 0;<br>public static void test() {<br> depth++;<br> try { test(); }<br> catch (StackOverflowError e) { System.out.println("safe depth ~ " + (depth - 1)); }<br>}
哪些递归场景最容易踩坑
不是所有递归都危险，但三类特别容易翻车：树形结构遍历（尤其非平衡二叉树）、解析嵌套 JSON/XML、以及把递归当 while 用却忘了收敛条件。
- 解析深层嵌套的 JSON 字符串时，Jackson/Gson 默认递归解析，遇到恶意构造的 500 层嵌套 JSON，
ObjectMapper.readValue()直接爆栈 - 自定义的
TreeNode遍历时，如果误把left或right指针连成环，递归永不停止，StackOverflowError是第一个报错，但根因是逻辑死循环 - 用递归实现斐波那契（
f(n) = f(n-1) + f(n-2)）看似教学友好，实际时间复杂度 O(2^n)，且 n > 10000 就大概率栈溢出——这种该用迭代或记忆化
替代方案比加栈更可靠
真需要处理深层嵌套？优先砍掉递归，改用显式栈（Deque）或队列（LinkedList），控制内存分配位置和生命周期。
- 树遍历改用
ArrayDeque<treenode></treenode>存待处理节点，每次 pop 一个、push 其子节点，避免方法调用栈累积 - JSON 解析可配 Jackson 的
JsonParser.Feature.STRICT_DUPLICATE_DETECTION+ 深度限制钩子，或换用流式 API（JsonParser）手动控制层级 - 若必须保留递归接口（如公共 SDK），在入口加深度计数器参数和阈值检查，比如
parse(json, depth + 1, MAX_DEPTH)，超限抛IllegalArgumentException而非等 JVM 崩
真正难的不是写对递归，是意识到：栈空间不属于你，它属于整个线程上下文；一次没崩，不代表下次不崩。
