栈帧结构决定每次递归新增固定开销，其大小由参数、局部变量和表达式嵌套决定，递归深度等于栈帧数量，栈总占用≈单帧大小×深度。
栈帧结构决定了每次递归都会新增固定开销
每个方法调用在 JVM 中不是“免费”的，它必须分配一个栈帧（Stack Frame），而这个栈帧包含局部变量表、操作数栈、动态链接和返回地址四部分。其中局部变量表按槽（Slot）分配，哪怕只声明一个 int 变量也要占 1 个槽；操作数栈默认深度为 0，但方法体越复杂，所需栈深度越大——这些都直接吃掉线程栈空间。
递归调用的本质，就是同一方法反复压入新栈帧。没有终止条件时，每轮调用都在复刻一套完整结构，而不是复用。这意味着：栈帧数量 = 递归深度，栈总占用 ≈ 单帧大小 × 深度。
- 单个栈帧大小由字节码决定，与源码行数无关，但与参数个数、局部变量数量、表达式嵌套层级强相关
- 64 位 Linux 下默认
-Xss是 1MB，按平均 2KB/帧估算，最多支撑约 500 层递归 - 若方法含大量
String参数或大数组引用，局部变量表膨胀，单帧可能达 4KB+，安全深度直接腰斩
从异常堆栈里反推栈帧堆积模式
遇到 java.lang.StackOverflowError 时，JVM 会输出最深的调用链片段。关键不是看“哪一行报错”，而是看“哪些方法在重复出现”：
Exception in thread "main" java.lang.StackOverflowError
at com.example.Calculator.fibonacci(Calculator.java:12)
at com.example.Calculator.fibonacci(Calculator.java:12)
at com.example.Calculator.fibonacci(Calculator.java:12)
...
连续多行相同方法名 + 相同行号，是典型无限递归；若出现 toString → hashCode → toString 循环，则可能是隐式递归（如对象自引用 + Jackson 序列化）。
- 注意行号是否一致：一致说明未进入分支逻辑，大概率缺终止条件
- 若行号递变（如 12→13→14），可能是深度嵌套而非递归，需检查调用链是否被框架自动增强（如 Spring AOP）
- 堆栈末尾突然截断（无省略号）且长度接近 1024 行，基本可判定已触达栈上限
用 jstack 观察真实栈帧数量与分布
jstack 输出的是线程快照，比异常堆栈更全。重点不是找错误，而是统计“当前线程栈中多少帧属于你的递归方法”：
jstack <pid> | grep -A 5 -B 5 "yourMethodName"
例如对 recursiveMethod 统计：
- 用
grep -c "recursiveMethod"粗略估算帧数（注意排除日志/代理方法干扰） - 观察帧之间是否有明显间隔：若有大量中间帧（如
invoke,doFilter,writeValueAsString），说明递归被框架拦截或增强，实际调用链比源码更长 - 对比不同线程的栈深度：若仅某个业务线程栈深异常，说明问题局限在该路径；若所有线程都深，可能是全局配置（如
-Xss过小）或共用工具类缺陷
调整 -Xss 不是万能解，反而可能掩盖设计缺陷
增大栈大小（如 -Xss2m）能让更深递归跑通，但这是在透支线程资源。每个线程栈都变大，意味着在同样堆内存下可创建的线程数下降——高并发服务容易因此触发 OutOfMemoryError: unable to create new native thread。
- 单线程栈从 1MB 增到 2MB，线程数理论减半；从 1MB 增到 4MB，可用线程数只剩 1/4
- 若递归深度超过 10000，即使设
-Xss8m也难保稳定，且无法解决根本的算法效率问题（如朴素斐波那契时间复杂度 O(2^n)） - 真正该做的，是把栈帧压力转移到堆上：用显式
Stack<integer></integer>模拟调用栈，或改写为迭代（while+ 状态变量）
栈帧结构本身不会变，但你怎么用它，决定了程序是稳健还是脆弱。最容易被忽略的，是局部变量表里那些看似无害的引用——它们让单帧变重，悄悄缩短了安全递归深度。
