StackOverflowError本质是调用栈溢出而非内存不足，主因是无限递归或循环引用；需通过异常堆栈定位重复调用链，聚焦toString/equals、递归终止条件、AOP自调用三类场景，结合-Xss调参验证与迭代替代等手段修复。
StackOverflowError 的本质是线程调用栈被撑满，不是内存不足，而是方法调用太深——绝大多数情况就是递归没出口或循环引用。它不走 try-catch，一发生就直接中断线程，所以必须从代码逻辑和调用链入手，不能靠堆内存那一套思路。
看异常堆栈，快速定位爆栈起点
错误日志里会打出超长的重复调用链，比如：
at com.example.User.toString(User.java:25)
at com.example.Order.toString(Order.java:42)
at com.example.User.toString(User.java:25)
at com.example.Order.toString(Order.java:42)
这种成对/周期性重复出现的方法名，基本锁定是循环引用（如 User 持有 Order，Order 又持有 User），toString()、equals()、JSON 序列化时极易触发。重点盯住最先开始重复的那一行，就是问题源头。
立即学习“Java免费学习笔记（深入）”；
如果看到大量 at java.util.ArrayList.get(ArrayList.java:...) 或 at com.xxx.Service.handle(...) 连续几十上百层，说明是深度递归或嵌套调用过深，不是无限循环，但规模已超出默认栈容量（通常 1MB）。
检查三类高频爆栈场景
不用全盘扫代码，先聚焦以下三处：
-
自定义 toString() / equals() / hashCode()：尤其用了 Lombok @Data 时，若实体间存在双向关联（如父子级联、订单-用户-地址），默认生成的 toString 会无限跳转；加
@ToString.Exclude或手动重写避开关联字段。 -
递归方法缺少终止条件或逻辑错误：比如写
factorial(n) { return n * factorial(n--); }，n-- 是先用后减，实际参数永远不变，等于无限递归；应改为n - 1。 -
AOP 代理或框架回调误触发自调用：Spring 中若 service 方法被 AOP 增强，又在方法体内直接调用
this.method()，可能绕过代理导致重复进入切面逻辑；统一改用serviceBean.method()或注入自身 Bean。
临时验证与根本修复策略
排查时可双管齐下：
-
加 JVM 参数快速验证：启动时加
-Xss2m（把单线程栈从默认约 1MB 提到 2MB）。如果加了之后错误消失，说明是深度合法调用但栈偏小；如果依然报错，那一定是逻辑死循环，参数无效，必须改代码。 - 用迭代替代递归：阶乘、树遍历、DFS 等场景，把递归改造成显式使用 Stack 或 Queue 的循环结构，彻底消除栈帧累积。例如递归版树遍历换成 while + Stack<Node>。
-
加递归深度防护：对无法避免的递归，入口处加计数器和阈值判断，比如
if (depth > 1000) throw new IllegalArgumentException("Recursion too deep");，避免无限制压栈。
IDE 和工具辅助定位
在 IntelliJ IDEA 中：
- 运行时报错后，直接点击堆栈里最顶部的 .java 行号，跳转到可疑方法；
- 右键方法名 → “Find Usages”，看是否被其他递归/循环调用路径间接触发；
- 开启调试模式，在疑似方法首行打条件断点，比如
depth > 500，让执行停在临界点前观察变量状态。
不复杂但容易忽略
