StackOverflowError本质是线程栈空间耗尽，由递归缺陷、对象图隐式循环、调用链过载引发；需优先代码修复（迭代替代递归、断开循环引用）、架构收敛深度、辅以jstack定位。
StackOverflowError 本质是线程栈空间耗尽，不是内存不够，而是调用链太深、压栈太多，超出了 JVM 给该线程分配的固定栈容量（默认约 1MB）。它和堆内存无关，所以调大 -Xmx 没用，关键在栈结构本身。
递归逻辑缺陷：出口错、写法错、深度失控
这是最直观也最常被忽视的原因。递归必须同时满足三个条件：有入口、有递推、有明确且可达的出口。
-
出口未生效：比如用
n--替代n - 1，导致参数不变，递归永不终止 -
出口不可达：初始输入跳过所有终止判断分支，例如传入负数却只检查
n == 0 -
合法但过深：阶乘计算
factorial(10000)或树高 5000 的遍历，即使逻辑正确，栈帧也会撑爆默认栈
对象图隐式循环：JSON、toString、Lombok 自动触发
代码里没写 return this.xxx()，却照样爆栈——这是“非显式递归”的典型场景。
- 双向关联模型（如 User ↔ Dept）被 Jackson 序列化时，会无限展开引用链：
User → dept → users → user → dept… - Lombok 的
@Data自动生成toString()，若字段含循环引用，打印日志瞬间就崩 - Spring AOP 代理配置错误，导致目标方法被反复拦截并重入，形成隐形调用环
调用链结构性过载：嵌套、代理、DSL 层层加码
现代框架抽象多，一层层封装可能把几行业务逻辑变成十几层方法调用。
- Spark 中连续使用
map → flatMap → filter → map → …十几次，每个算子都是一次方法调用，栈帧逐层堆积 - MyBatis Plus 的 LambdaQueryWrapper 链式调用过长，配合复杂条件构造器，也可能逼近栈深极限
- 自定义注解处理器 + AOP + 拦截器 + 过滤器叠加，一次 HTTP 请求触发七八层环绕增强
调优不是只加 -Xss：三类策略要分清用
盲目调大栈空间（如 -Xss4m）能临时绕过问题，但掩盖了设计隐患，还可能挤占系统线程资源。
-
代码级修复优先：用迭代替代递归（如斐波那契、DFS 改为栈模拟）；用
@JsonIgnore或@JsonBackReference断开 JSON 循环；Lombok 改用@ToString(exclude = "xxx") -
架构级收敛调用深度：拆分过长链式操作；避免在 toString/log/debug 中触发复杂对象图遍历；限制 AOP 切点粒度，不用
execution(* *(..))全局匹配 -
运行时辅助手段：用
jstack <pid>快速抓取线程栈快照，定位重复出现的方法名；生产环境可加-XX:+PrintGCDetails辅助排除是否混入堆问题
