栈帧压入过程直接暴露递归深度瓶颈：每次递归调用都独立分配新栈帧，含局部变量、返回地址等，不可复用；栈空间固定（如JVM默认1MB），压入快于弹出，base case失效或参数不收敛将导致持续压栈直至溢出。
栈帧压入过程直接暴露递归深度瓶颈
每次递归调用都会生成一个新栈帧，它不是“复用”上一层的内存，而是独立分配——局部变量表、操作数栈、动态链接、返回地址全都要拷贝一份。这意味着 fibonacci(50) 这种未经优化的递归，实际会创建远超 50 层的栈帧（因重复子问题），每层还携带参数、中间变量等数据。栈帧数量 = 调用深度，而 JVM 线程栈总空间是固定的（默认约 1MB），压入速度远快于弹出速度，溢出只是时间问题。
为什么 base case 缺失或浮点数判等会卡死在栈帧堆积
终止条件失效时，JVM 不知道该“弹出”哪一帧，只能继续压入。常见陷阱包括：
-
if (n == 0.0)判 double 类型：浮点精度误差导致永远不满足，recursiveMethod(1.0)可能变成recursiveMethod(0.9999999999999999)→recursiveMethod(0.8999999999999999)… 持续压栈 -
if (obj.equals(null))但obj是未重写equals()的自定义对象：引用比较失败，逻辑永远进不了 return 分支 - 递归参数未严格收敛：比如
n = n / 2用整数除法时，n=1后再除还是 1，base case永远不触发
-Xss 参数只能延缓崩溃，不能替代逻辑兜底
调大栈大小（如 -Xss2m）只是把溢出阈值从约 2000 层推到 4000 层，但只要递归没终止，它迟早耗尽。更危险的是：增大 -Xss 会挤占堆内存，多线程场景下还可能因总内存超限引发 OutOfMemoryError: unable to create new native thread。真正有效的做法是：
- 用迭代重写，手动维护状态（如用
Deque存参数和中间结果） - 对必须递归的场景，加深度计数器，超过阈值主动抛
IllegalArgumentException - 避免在递归路径中创建大对象或长数组——单个栈帧过大，会更快填满栈空间
调试时怎么看栈帧真实占用？
别只盯着异常堆栈最上面几行。用 jstack -l 抓线程快照，重点看：
- 同一方法名连续出现几十上百次（如全是
compute(...)），说明递归未退出 - 每个栈帧的局部变量表是否包含大量引用或大数组（
jstack不显示具体值，但可通过代码反推） - 线程状态是否长期为
RUNNABLE却无进展——大概率卡在深层递归里
复杂点在于：栈帧本身不可见，你只能通过调用链长度、参数变化趋势、以及是否出现重复计算（如斐波那契中 fibonacci(3) 出现多次）来反推结构缺陷。逻辑没闭环，栈就停不下来。
