Java递归深度由线程栈大小（-Xss）和每层栈帧开销共同决定，非固定值；空递归约10000层，加局部对象后骤降至2000层以下，调大-Xss可提升深度但受限于内存与线程数。
Java递归调用深度由栈大小决定，不是固定值
Java没有硬编码的“最大递归层数”，实际能跑多少层，取决于每个方法调用占用的栈帧大小和JVM分配的线程栈容量。默认情况下，-Xss 通常为1MB（HotSpot 64位常见值），但不同JDK版本、操作系统、甚至是否开启调试模式都可能影响实际可用栈空间。
一个空递归函数（只调用自己、无局部变量）在默认栈下大概能撑到 ~10000 层；但只要加几个对象引用或大数组局部变量，可能跌到 ~2000 甚至更低。
-
-Xss512k会让深度直接腰斩，-Xss2m可能翻倍——但它不能无限加，系统线程数和内存总量会成为新瓶颈 - 递归方法参数是对象引用？没问题；但传
new byte[1024]进去？每层多占1KB，深度立刻崩塌 - 启用
-XX:+UseCompressedOops（默认开启）能略微减小栈帧，但效果有限，别指望靠它救深递归
StackOverflowError 出现时，根本不是“递归太多”，而是“栈被填满了”
抛出 java.lang.StackOverflowError 的那一刻，说明当前线程的栈空间已耗尽，无法再压入新的栈帧。它不区分你是递归、嵌套回调、还是疯狂的 lambda 链式调用——只要栈满就报错。
典型误导场景：fib(50) 没问题，但 fib(10000) 崩了，很多人以为是算法问题，其实是栈不够；换成尾递归优化（Java不支持）或改循环，错误就消失——但错误本身从不提“递归”，只说“stack overflow”。
立即学习“Java免费学习笔记（深入）”；
- 用
jstack <pid>看线程栈，如果看到几百/几千行重复的同一方法名，基本锁定是递归失控 - IDE调试时步进递归，观察栈帧数量增长趋势，比猜“是不是到极限了”更可靠
-
Thread.currentThread().getStackTrace()在运行时取栈，可用于监控临界深度，但别在每层都调——它自己就建栈帧
想测准自己环境的临界深度？写个可配置的探测函数
别依赖网上查到的“一般10000”，不同JVM参数组合下结果差异极大。最稳妥的方式是实测，而且要贴近真实方法结构——比如你实际递归的是带 String 拼接和 HashMap 查找的方法，探测函数就得模拟这个开销。
public static int maxDepth() {
return maxDepth(0);
}
private static int maxDepth(int depth) {
// 模拟业务开销：局部变量 + 方法调用
String s = "x";
HashMap<String, Integer> map = new HashMap<>();
map.put(s, depth);
return maxDepth(depth + 1); // 不加终止条件，纯压栈
}
- 运行前加
-Xss256k和-Xss2m分别跑，记录各自触发StackOverflowError时的depth值 - 把探测方法改成
static，避免实例字段干扰；去掉所有synchronized或锁逻辑，防止额外栈消耗 - 注意：JIT可能对空递归做优化（如栈替换），加点真实操作（如上面的
map.put）能抑制这种优化，让测试更贴近生产
递归深度问题从来不是单点问题，而是栈、GC、线程模型三者咬合的结果
你以为调大 -Xss 就万事大吉？未必。更大的栈意味着每个线程吃更多内存，线程数上限下降；而频繁创建线程（比如用 ForkJoinPool 跑递归任务）还可能触发 OutOfMemoryError: unable to create native thread。
更隐蔽的是GC压力：深递归中大量短命局部对象（尤其字符串拼接、流式API）会让年轻代快速填满，GC频率上升，间接拖慢递归执行节奏，甚至让栈耗尽前先卡死。
- 用
-XX:+PrintGCDetails观察递归过程中的GC行为，如果发现 Minor GC 频次异常高，说明局部对象正在反向挤压栈空间 - 不要在递归里反复创建
SimpleDateFormat或StringBuilder实例——复用它们比调大栈更有效 - 异步递归（如
CompletableFuture链）看似绕开了栈限制，但本质是把调用压到了堆上，OOM风险转向了堆内存
真正难处理的，永远是那些“看起来没几层，却突然爆栈”的 case——往往因为某次调用触发了反射、代理、或日志框架的深层嵌套，栈帧结构远超预期。这时候光看自己的方法没用，得用 jstack 抓现场。
