StackOverflowError 出现在递归调用栈压得太深的最外层重复方法上，而非最深层；定位需看异常堆栈末尾连续出现的同一方法名及其重复次数。
StackOverflowError 出现在哪一层调用上
Java 没有尾递归优化，StackOverflowError 一定是因为调用栈压得太深，不是逻辑错，是栈空间被耗尽。JVM 默认线程栈大小约 1MB（不同版本/平台有差异），每层递归至少占几百字节（局部变量、PC 记录、栈帧元数据），粗略算下来，纯递归函数大概在 1000–5000 层就可能崩，具体看方法体大小。
定位关键：加 -XX:+PrintStackTraceOnCrash（JDK 19+）或直接看异常堆栈末尾重复出现的同一行——那里就是递归入口点，不是“最深”那层，而是“反复跳转”的那个 methodA 或 dfs。
- 别只看报错行号，要数堆栈里相同方法名连续出现的次数，它接近实际递归深度
- 如果堆栈里夹杂
lambda$或$$Lambda$，说明是函数式写法触发的，同样无尾优化 - 用
jstack <pid>抓现场线程栈，比跑一次再崩溃更准
把递归改写成 while 循环的实操要点
几乎所有非树形分支的递归都能转为迭代。核心是把“待处理状态”显式存进集合（如 Stack、Deque），而不是靠调用栈隐式保存。
比如计算阶乘、遍历单链表、二分查找这类线性递归，直接用 while + 变量更新就行；但像 DFS 遍历图、表达式求值这种，就得手动模拟栈。
立即学习“Java免费学习笔记（深入）”；
- 原始递归参数变成循环内的局部变量或栈元素字段，例如
dfs(node, depth)→ 改成stack.push(new State(node, depth)) - 递归终止条件（
if (base) return）变成while (!stack.isEmpty())内的if (base) continue或直接跳过入栈 - 别漏掉“回溯逻辑”：递归里自然出栈，迭代里得手动 pop 或用不可变对象避免状态污染
-
Deque比Stack更快更安全，优先用ArrayDeque
示例：原递归求斐波那契第 n 项（不推荐但典型）f(n) = f(n-1) + f(n-2)，改成迭代只需两个变量滚动，完全不用栈——说明不是所有递归都必须用栈模拟，先想清楚是否真需要“多路分支暂存”。
什么时候该换算法，而不是硬改递归
有些问题天生适合递归，比如八皇后、语法树解析、分治排序。硬改成迭代不仅难读，还可能引入新 bug。这时更该考虑：是不是输入规模不合理？或者有没有更合适的抽象？
- 如果是处理外部数据（如 JSON 深嵌套、XML 层级过深），优先在上游限制深度，加
maxDepth校验，抛IllegalArgumentException比等StackOverflowError好调试 - 树形结构遍历，如果深度不可控，改用 BFS（队列）+ 深度计数，比 DFS 迭代更省内存且易中断
- 涉及大量中间状态缓存的（如动态规划递归解法），直接上
Map<State, Result>记忆化，往往比改循环更快见效 - 别碰 JNI 或字节码插桩做“伪尾递归”，Java 语言层没标准支持，维护成本远高于重构
为什么 Java 不支持尾递归优化
不是 JVM 技术做不到，而是设计取舍：Java 要保持栈帧完整以支撑调试、异常堆栈、安全管理器（SecurityManager）、以及 Thread.getStackTrace() 这类 API。尾调用优化会合并栈帧，导致这些能力失效。
对比 Scala 编译器能加 @tailrec 注解并报错提醒，是因为它在编译期重写字节码；而 Java 的 javac 不做这层转换，JVM 也未暴露相关指令（虽然 HotSpot 内部有部分 tail-call 相关实验代码，但从未启用）。
- JDK 17+ 的
ScopedValue和虚拟线程（VirtualThread）进一步弱化了对传统栈深度的依赖，但不改变递归本身行为 - 如果真需要尾递归语义，可选 Kotlin（编译期转循环）或用 Trampoline 模式（返回
Supplier<Result>链），但会增加 GC 压力
真正卡住的从来不是“能不能加个 flag 开启尾递归”，而是调用栈信息一旦丢失，线上排查 NullPointerException 都会少三层上下文——这个代价，Java 团队至今认为不值得。
