问题
有一个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 打破循环依赖（推荐），或增加栈大小（临时方案）