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> 抓取线程快照，对比正常线程与出问题线程的栈深度——若多数线程栈深 200，出错线程达 2000，大概率是逻辑缺陷
• 检查涉及的对象模型：是否存在父子双向引用、集合中包含自身等循环结构，特别注意 toString() 和序列化逻辑
• 审查递归函数：确认终止条件是否可达、参数是否严格向出口收敛、是否有意外的重载或代理干扰

解决方案与避坑提醒

修复优先级：改代码 > 调参数。盲目增大栈大小（如 -Xss2m）可能掩盖问题，甚至引发线程数锐减、连接超时等新故障。

• 递归改迭代：对深度不确定的场景（如树遍历、表达式求值），优先用显式栈（Deque）替代系统栈
• 加深度防护：递归入口处校验当前调用层级，超阈值直接抛业务异常，避免静默崩溃
• 拆解大方法：把长调用链中的中间逻辑提取为独立方法，降低单帧开销；避免在栈上分配超大临时变量
• 禁用危险自动生成：Lombok 的 @Data 在循环引用结构中慎用，可改用手动 toString() 并跳过关联字段