递归深度溢出阈值不固定为1000，而取决于JVM默认栈大小（约1MB），通常在1000–8000间触发StackOverflowError；根本原因是每次调用压入栈帧，含参数、局部变量和返回地址；Java不支持尾递归优化，须显式转循环或用Deque模拟栈；树遍历、分治、回溯等场景可保留递归，但需限深、拆段、避大对象；异步化不能简单用CompletableFuture递归，易引发OOM。
递归深度超过1000就容易栈溢出？
不是固定1000，但JVM默认栈大小（通常1MB左右）下，深度约在1000–8000之间就会触发StackOverflowError。根本原因不是“调用次数多”，而是每次递归都压入栈帧——保存局部变量、参数、返回地址。哪怕方法体只有return，也占空间。
实操建议：
- 用
-Xss参数临时调大栈（如-Xss2m），仅限排查或极少数必须深递归的场景；生产环境不推荐，可能挤占堆内存或引发线程创建失败 - 加深度计数器，在入口处判断
depth > 1000就抛IllegalArgumentException，比等栈溢出再崩溃更可控 - 注意：递归调用链中若含lambda、匿名内部类或反射调用，栈帧更大，安全阈值要更低
尾递归优化Java能用吗？
不能。Java语言规范不支持尾递归优化（TCO），JVM也未实现。写成尾递归形式（最后一个操作是递归调用）毫无意义——字节码仍是普通方法调用，栈照样涨。
常见错误现象：
立即学习“Java免费学习笔记（深入）”；
- 误以为把
return f(n-1)改成return f(n-1, acc)就能避免溢出 - 照搬Scala/JavaScript写法，结果运行时照样
StackOverflowError
替代方案只有显式转为循环：while + 状态变量，或用Deque模拟调用栈。
哪些递归场景真没法不用？
树形结构遍历（如AST解析、JSON嵌套对象展开）、分治算法（归并排序、快速幂）、回溯（N皇后、全排列）——这些天然递归，强行转迭代会显著增加代码复杂度和出错概率。
这时优先做三件事：
- 确认输入规模上限：比如解析JSON，限制最大嵌套深度为
maxDepth=200，超限直接拒绝 - 把递归拆成“可中断”段：例如处理子树前先检查
Thread.currentThread().isInterrupted()，配合超时控制 - 关键路径避免在递归中创建大对象（如
new byte[1024]），否则栈+堆双重压力
用CompletableFuture把递归扔到线程池里行不行？
不行。这只会把栈溢出从主线程转移到工作线程，而且更糟——线程池默认栈大小通常更小（如ForkJoinPool用-Xss1m），还可能拖垮整个池。
真正有效的异步化，是把“递归”逻辑改为事件驱动或分片提交：
- 用
ExecutorService.submit()逐层提交子任务，但每个任务只处理一层，靠thenCompose串起结果 - 对大数据集，改用
ForkJoinTask，它有工作窃取机制，且栈使用更紧凑 - 警惕：
supplyAsync+ 递归调用 = 隐式无限线程创建，极易OOM
递归的边界感比技巧更重要——什么时候该停，比怎么写更难把握。
