stackoverflowerror本质是线程虚拟机栈空间耗尽，无法压入新栈帧；它属error级别，不可try-catch捕获，必须代码修复，主因是递归失控（无终止条件、终止失效、深度超限）及隐式循环调用。
Java栈溢出本质是线程的虚拟机栈空间被耗尽，无法再压入新的栈帧。它不是能靠 try-catch 捕获的异常，而是 JVM 抛出的 Error，说明程序逻辑已出现严重缺陷，必须从代码层面修复。
最常见原因：递归失控
90% 以上的 StackOverflowError 都源于递归问题，但表现形式不同：
-
没有终止条件：方法无条件调用自身，如
void f() { f(); } -
终止条件写错：比如用
n--替代n - 1，导致参数不变，递归永不退出 - 递归深度合理但栈太小：例如默认栈 1MB 下，深度超 1500 层就可能溢出（尤其含较多局部变量时）
- 隐式递归：toString()、equals()、JSON 序列化中因对象循环引用，触发无限链式调用
其他典型诱因
递归之外，这些情况也容易踩坑：
- 方法循环调用：A 调 B，B 又调 A，形成闭环，和无限递归效果一致
-
超大局部变量：在方法内声明巨型数组（如
new byte[1024 * 1024]），一次性占满栈空间 - AOP 或代理配置错误：Spring 中切面逻辑误将目标方法再次代理，造成 self-invocation 死循环
- 构造器链异常：类 A 构造器中创建类 B 实例，B 构造器又创建 A 实例，间接循环依赖
快速定位方法
别急着改代码，先确认问题根源：
- 看堆栈日志：错误信息末尾会重复出现同一行或少数几行方法调用，这就是爆栈热点
- 用
jstack -l <pid></pid>抓现场线程快照，对比正常线程与报错线程的栈深度——若其他线程栈深 200，出问题的才 350，基本可排除栈大小问题 - 检查 toString / equals / hashCode / JSON 序列化相关类，重点排查双向关联（如 Parent ↔ Child）
- 搜索项目中所有递归方法，逐个验证终止条件是否可达、参数是否真在收敛
可靠解决路径
优先修复代码，而非调大栈：
- 递归转迭代：用显式栈（
Stack或Deque）或队列模拟调用过程，彻底规避栈帧累积 - 加深度防护：在递归入口处加计数器，达到阈值（如 1000）直接抛业务异常，避免静默崩溃
- 拆分高耦合逻辑：把长调用链中的中间层提取为独立方法，降低单次栈帧复杂度
- 慎用
-Xss：仅当确认递归深度合理且不可降（如解析超深嵌套 JSON）时临时调整，如-Xss2m；但要同步评估线程数上限，防止内存耗尽
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
