stackoverflowerror发生在调用栈反复压入同一方法导致空间耗尽的临界点，而非最深层；定位关键在于识别堆栈底部连续重复的方法名及其出现次数，该次数即近似递归深度。
StackOverflowError 不是发生在“最深那一层”，而是出现在调用栈反复压入同一方法、最终耗尽空间的临界点。定位递归深度，关键不是数总层数，而是识别**重复出现的调用模式**和**实际触发崩溃的入口位置**。
看异常堆栈末尾的连续重复方法名
抛错时的堆栈信息从上到下是“最新调用→最早调用”。真正要盯的是**底部（即堆栈最末几行）**：那里会密集出现同一个方法名（比如 calculate、dfs 或带 lambda$ 的匿名方法）。连续出现多少次，就大致等于当前递归深度。
- 例如堆栈底端连续 1287 行都是
com.example.TreeUtil.traverse(Node)，说明这次崩溃前已递归约 1287 层 - 如果夹杂
$$Lambda$123/0x0000000800c1a000.apply，说明是函数式写法隐式递归，同样按重复次数估算深度
用 JVM 参数展开完整堆栈并辅助计数
默认堆栈可能被截断（尤其深度大时），加参数确保看到全貌：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 启动时加 -XX:MaxJavaStackTraceDepth=-1：禁用截断，显示全部栈帧（注意会略拖慢异常抛出）
- 配合 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps：排除因频繁 GC 触发 Finalizer 导致的伪递归干扰
- 在 IDE 的 Debug Configurations → VM options 中添加上述参数，便于调试时直接观察
运行时打点验证参数变化趋势
光看堆栈还不够，需确认递归是否真的在收敛：
- 在递归方法入口加日志：
System.out.println("depth=" + depth + ", n=" + n); - 或设断点，单步执行几次，观察参数（如索引、计数器、节点值）是否单调趋近边界条件
- 若发现
n从 10 → 9 → 8 → … → 1 → 0 → -1 → -2 持续递减，说明终止条件漏了负数分支，不是深度问题，而是逻辑缺陷
用 jstack 抓现场线程快照
对正在运行的服务，可不重启直接诊断：
- 执行 jstack -l
获取所有线程栈 - 过滤出
java.lang.Thread.State: RUNNABLE且栈深度明显异常（如超 1000 层）的线程 - 重点看该线程栈底是否持续循环调用某几个方法（如 A→B→C→A），这属于间接递归，比单方法自调更难察觉
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
