防范 StackOverflowError 的核心是控制调用栈深度与单帧开销，关键在于确保递归有明确、可达且前置的终止条件，避免依赖外部状态，并用最小输入手动验证。
防范 stackoverflowerror 的核心是控制单线程内方法调用栈的深度与单帧开销，而不是盲目加内存。它本质是逻辑问题，不是资源问题。
确保每个递归都有明确、可达的终止条件
这是最常见也最容易被忽视的根源。终止条件必须在所有执行路径中都能被访问到，且不能依赖外部状态（如未初始化的变量或异步结果）。
- 写完递归函数后，手动代入最小输入（如 n = 0 或 null）验证是否立即返回
- 避免把终止判断写在分支末尾却忘了 else 分支——用 guard clause 风格前置检查更安全：if (n
- 对树、图等结构递归时，额外加深度计数器并设上限（例如 maxDepth <= 1000），防止意外陷入环或极深结构
优先用迭代替代深层递归
递归简洁，但 JVM 栈帧是固定开销；迭代把“调用状态”显式搬到堆上，可控性高得多。
- 遍历文件目录、解析嵌套 JSON、DFS/BFS 遍历图结构等场景，改用 显式栈（Stack<T>）或队列（Queue<T>） 模拟调用过程
- 阶乘、斐波那契等纯计算类递归，直接转为 for 循环，零栈帧增长
- 若必须保留递归语义（如算法教学），可考虑尾递归优化（Java 本身不支持，但可用循环+状态变量模拟）
警惕非显式递归：toString()、equals()、JSON 序列化等隐式调用链
这些方法看似普通，一旦内部触发对象自引用或循环引用，就会瞬间压爆栈。
- 重写 toString() 时，不要直接打印 this 或调用其他可能间接引用自身的字段
- 使用 Jackson / FastJSON 时，对可能存在循环引用的对象加 @JsonIgnore 或配置 ObjectMapper.enable(SerializationFeature.FAIL_ON_SELF_REFERENCES)
- 实体类之间双向关联（如 User ↔ Order）务必检查 Lombok @Data 是否意外启用了递归 getter
合理设置 -Xss 并监控真实栈占用
增大栈大小只是兜底手段，但对排查和容量规划有意义。默认值（通常 512KB–1MB）在多数业务场景下已足够，盲目调大反而掩盖问题。
- 线上环境建议统一设为 -Xss1m，避免不同机器因默认值差异导致行为不一致
- 用 jstack -l [pid] 抓取线程快照，观察报错线程的栈帧是否大量重复同一方法（典型无限递归特征）
- 结合 Arthas 的 thread -n 5 查看最深的 5 个线程调用栈，快速定位异常热点
