stackoverflowerror是线程栈空间耗尽所致，主因是无限递归，其次为深度嵌套调用、超大局部变量及循环方法调用；须通过堆栈分析定位问题，优先修复代码而非增大-xss参数。
线程栈溢出（StackOverflowError）本质是单个线程的调用栈被撑满，无法再分配新栈帧。它不是内存泄漏，也不是堆溢出，而是 JVM 为该线程预设的栈空间（默认约 1MB）被耗尽。这个错误属于 Error，不可捕获、不应捕获，必须从代码逻辑层面修正。
最常见原因：无限或失控的递归
90%以上的 StackOverflowError 源于递归没写好。只要方法调用自己（或间接调用自己），且没有有效终止条件或终止条件永远不满足，就会持续压栈，直到栈满。
- 典型错误：递归参数未真正递减，比如写成
n--而非n - 1，导致下一层仍传入原值 - 隐式递归：
toString()、equals()或 Lombok 自动生成的方法，因对象间循环引用（如 A→B→A）而反复调用 - 框架场景：Spring AOP 配置错误，导致代理方法反复调用自身，形成调用环
其他关键诱因
递归之外，还有几类容易被忽略的触发点：
- 深度嵌套调用：非递归但方法链极长（如 A→B→C→…→Z 连续几十上百层），尤其在解析复杂嵌套结构（XML/JSON）时易出现
-
超大局部变量：在方法内声明巨型数组（如
new byte[1024 * 1024]）或大量基本类型变量，单次调用就占满栈空间 - 循环方法调用：两个或多个方法互相调用（A→B→A→B…），逻辑上等价于无限递归，堆栈轨迹会交替显示多个方法名
高效排查步骤
别急着调大栈参数，先确认是不是代码问题：
- 看异常堆栈：复制报错最顶部 5–10 行，观察是否重复出现同一方法名（无限递归）或规律性交替（循环调用）
- 用
jstack -l <pid></pid>抓取线程快照，对比正常线程与出问题线程的栈深度——若多数线程栈深 200，出错线程达 2000，大概率是逻辑缺陷 - 检查涉及的对象模型：是否存在父子双向引用、集合中包含自身等循环结构，特别注意
toString()和序列化逻辑 - 审查递归函数：确认终止条件是否可达、参数是否严格向出口收敛、是否有意外的重载或代理干扰
解决方案与避坑提醒
修复优先级：改代码 > 调参数。盲目增大栈大小（如 -Xss2m）可能掩盖问题，甚至引发线程数锐减、连接超时等新故障。
- 递归改迭代：对深度不确定的场景（如树遍历、表达式求值），优先用显式栈（
Deque）替代系统栈 - 加深度防护：递归入口处校验当前调用层级，超阈值直接抛业务异常，避免静默崩溃
- 拆解大方法：把长调用链中的中间逻辑提取为独立方法，降低单帧开销；避免在栈上分配超大临时变量
- 禁用危险自动生成：Lombok 的
@Data在循环引用结构中慎用，可改用手动toString()并跳过关联字段
