Spring boot服务启动报错 java.lang.StackOverflowError 原因分析

问题

有一个spring boot框架的服务发布到生产环境后启动报错：java.lang.StackOverflowError，本地启动没有报错，为什么？

原因总结

直接原因：栈空间太小（228KB）。Xss参数：每个线程的栈大小。用于存储局部变量、方法调用的参数、返回值以及方法调用的上下文信息。 – 为什么xss设置228KB(jdk8默认已经1MB)，当初调参的同事反馈为了调优。

根本原因：类加载和反射阶段需要深层调用链

触发因素：循环依赖使调用链更深，更容易暴露问题

解决方案：使用 @Lazy 打破循环依赖（推荐），或增加栈大小（临时方案） – 我们临时调大栈大小，228KB->1MB

核心要点

1. 循环依赖不是唯一原因

没有循环依赖时，如果类结构复杂、调用链深，也可能因为栈空间小触发 StackOverflowError。

2. 循环依赖与 StackOverflowError 的关系

循环依赖不是根本原因，而是触发因素：

根本原因：栈空间太小（228KB）

触发因素：循环依赖使调用链更深

具体机制：

类加载阶段，Spring 需要解析类的结构（方法、字段、构造函数）

ReflectionUtils.getDeclaredMethods 会递归处理类及其父类、接口

存在循环依赖时：

解析 A 类 → 发现依赖 B → 解析 B 类 → 发现依赖 A → 可能需要再次验证 A

调用链可能从 100 层加深到 120-150 层

228KB 栈空间只能容纳约 114 层调用，容易溢出

1MB 栈空间可容纳约 512 层，足够

3. 为什么研发环境没问题？

可能原因：

研发环境 JVM 参数不同（可能默认 1MB）

类加载顺序不同

JVM 版本或优化差异

4. 解决方案

已添加 @Lazy 注解，这会：

打破循环依赖，减少调用链深度

延迟 Bean 初始化，避免在类加载阶段同时解析两个类

即使栈空间较小也能正常工作

5. 总结

直接原因：栈空间太小（228KB）

根本原因：类加载和反射阶段需要深层调用链

触发因素：循环依赖使调用链更深，更容易暴露问题

解决方案：使用 @Lazy 打破循环依赖（推荐），或增加栈大小（临时方案）