stackoverflowerror本质是线程栈空间耗尽，而非内存不足；由递归缺陷、隐式循环引用、调用链过载或局部变量过大导致栈帧持续压入，超出jvm固定栈容量（默认约1mb）。
StackOverflowError 的核心不是内存不足，而是线程栈空间被填满——每次方法调用都压入一个栈帧，递归过深时，这些栈帧层层堆叠，最终超出 JVM 为该线程分配的固定栈容量。
为什么递归会直接压爆栈？
JVM 每个线程启动时就划定了独立的栈空间（默认约 1MB），由 -Xss 参数控制。这个空间不能动态扩容，所有栈帧必须挤在里面。
- 每个栈帧包含局部变量表、操作数栈、动态链接和返回地址；变量越多、参数越复杂，单帧越大
- 递归没出口 → 帧无限压入 → 栈顶撞到边界 → JVM 立即抛出 StackOverflowError
- 即使逻辑正确，factorial(10000) 或遍历深度 3000 的树，也可能撑爆默认栈
关键触发条件：不只是“递归没写好”
除了显式无限递归，以下情况同样会悄无声息地耗尽栈空间：
- toString() 或 JSON 序列化引发隐式递归：比如两个对象互相引用，Lombok 自动生成的 toString() 会来回调用，形成循环压栈
- 代理/增强类嵌套调用：Spring AOP、CGLIB 生成的代理方法若与原方法形成调用闭环，也会累积栈帧
- 局部变量爆炸：一个方法里声明几十个大数组或大对象引用，单帧体积激增，有效深度大幅缩水
-Xss 参数的实际影响与调优建议
-Xss 控制的是每个线程的栈大小，单位可为 k（KB）、m（MB）。它不解决逻辑问题，但能改变溢出阈值：
- 设太小（如 -Xss128k）：轻度递归就报错，适合排查栈敏感场景
- 设太大（如 -Xss4m）：单线程更耐深调用，但总内存占用上升，尤其在线程数多时易触发 OOM
- 生产环境建议保持默认（-Xss1m），优先修复代码；仅当确认是合法深度且无法改迭代时，再小幅上调（如 -Xss1536k）
比调参更有效的三种落地解法
真正稳住栈，靠的不是加内存，而是减压栈：
-
递归转迭代：用显式栈（Stack
）或队列模拟调用过程，把栈帧压力从 JVM 转移到堆内存 - 拆分调用链：把长链方法（A→B→C→D→E）改为分段执行，中间结果落库或缓存，避免单次调用过深
- 主动截断+降级：对树/图遍历等场景，加深度计数器，超限后跳过子节点或返回简化结果
