stackoverflowerror是jvm报出的error，无法用try-catch安全捕获，本质是线程栈被撑满，主因是无限递归或隐式调用环；需通过jstack定位重复栈帧、检查tostring/equals等隐式递归及循环引用，并优先改递归为迭代。
StackOverflowError 不是异常，而是 JVM 报出的错误（Error），无法用 try-catch 捕获，必须从调用逻辑本身定位和修复。它本质是单个线程的虚拟机栈被撑满，无法再压入新栈帧，最常见原因是无限递归或调用环，而非内存不足。
看堆栈日志，快速识别模式
报错时堆栈顶部通常有强提示：
- 如果连续几十行都是同一方法名（如 parseJson → parseJson → parseJson…），基本就是无限递归，检查终止条件是否可达、参数是否真正变化（比如误用
n--而非n - 1） - 如果交替出现两个方法（如 loadData → validate → loadData → validate…），说明存在 A→B→A 的循环调用，检查代理、回调或框架拦截逻辑
- 如果堆栈中反复出现
toString、hashCode或equals，重点查对象模型——是否存在 A 引用 B、B 又引用 A 的双向关系，尤其 Lombok@Data自动生成的方法容易触发隐式递归
用 jstack 抓线程快照对比深度
运行中服务发生 StackOverflowError 时，JVM 往往来不及输出完整堆栈。此时可立即执行：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
jstack -l <pid></pid>获取当前所有线程栈，搜索java.lang.StackOverflowError所在线程 - 观察该线程栈帧数量：正常线程栈深多在 50–200 层，出问题的线程常达 1500+ 层，且帧内容高度重复
- 对比其他健康线程的调用链，快速定位异常起始点（例如都卡在某个 XML 解析器或自定义序列化工具里）
检查异常链是否形成循环引用
当错误伴随异常包装（如 throw new RuntimeException("wrap", e)）时，需警惕 cause 循环：
- 在 IDE 调试时，在抛异常前用 Evaluate Expression 检查：
e.getCause() == e或e.getCause().getCause() == e - 特别注意第三方库行为：Spring 的
ExceptionTranslator、MyBatis 的异常转换器，某些旧版本存在未校验 cause 的 bug - 避免手动调用
initCause()形成闭环，如e1.initCause(e2); e2.initCause(e1);
加防护和辅助参数缩小排查范围
不建议直接调大 -Xss，但可用以下参数争取线索：
-
-XX:MaxJavaStackTraceDepth=1000：增大栈轨迹打印上限，让报错时多输出几层调用，便于人工识别规律 -
-XX:+PrintStackTraceAtUncaughtException（部分 JDK 支持）：在未捕获异常抛出时强制打印栈 - 启动时注册全局处理器：
Thread.setDefaultUncaughtExceptionHandler，捕获StackOverflowError并记录线程名、时间、当前异常对象哈希值，辅助回溯
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
