stackoverflowerror是因线程调用栈耗尽导致的virtualmachineerror，主因包括：①递归无终止条件；②递归深度超栈容量；③隐式循环调用；④单方法栈帧过大。
StackOverflowError 发生，是因为线程的调用栈空间被耗尽，JVM 无法再为新方法调用分配栈帧。它不是普通异常，而是 VirtualMachineError 的子类，说明 JVM 自身运行环境已出问题，无法继续安全执行。
递归缺少终止条件
这是最常见、最典型的成因。只要递归调用没有明确的退出分支，就会无限压栈。
- 每次调用都生成一个新栈帧，保存参数、局部变量和返回地址
- 栈帧持续累积，直到超出线程栈上限（默认通常 128KB–1MB，取决于 -Xss 设置）
- 示例：直接调用自身且无判断
递归深度过大
即使有终止条件，若递归层数远超栈容量，仍会溢出。比如计算 fibonacci(10000) 或 factorial(50000)。
- 每层递归至少占用几百字节栈空间（含参数、返回地址、操作数栈等）
- 默认栈大小下，安全递归深度通常在几千层以内，具体取决于方法复杂度
- 阶乘、斐波那契等朴素递归空间开销线性增长，极易触顶
隐式循环调用
不一定是显式递归，方法之间互相调用形成闭环，也会不断入栈。
立即学习“Java免费学习笔记（深入）”；
- 例如 A → B → C → A，或重写 toString() 时又调用了包含自身的对象打印
- equals() / hashCode() 实现中误调用本对象的其他方法，引发间接自调用
- 框架代理、AOP 增强后未注意调用链，也可能意外引入环路
单次方法占用栈空间过多
一个方法里定义大量局部变量、大数组、多维嵌套结构，或使用巨量 try-catch 块，也会快速吃掉栈空间。
- 局部变量表膨胀、操作数栈预留空间变大，导致单个栈帧体积激增
- 尤其在深度调用链末端再叠加大栈帧，更容易突破阈值
- 这种场景在生成代码、模板渲染、解析器递归下降中较常见
基本上就这些。关键不在“能不能递归”，而在于“是否可控、可收敛、栈开销是否合理”。
