递归不触发gc但会加重其压力，因栈溢出与堆gc无关；java不支持尾递归优化，需改用显式栈+循环、复用对象、控制临时分配来降低gc频次。
递归过程本身不直接触发垃圾回收（GC），但深度或高频递归会显著影响内存行为，间接加重 GC 压力。关键要分清：栈空间和堆空间的管理是两回事——Java 的 GC 只管堆，不管栈；而递归爆掉的是栈（Stack Overflow），不是堆（OutOfMemoryError）。所以“递归中的垃圾回收优化”这个说法容易误导，真正要做的，是避免让递归拖垮栈，同时减少递归在堆上制造的临时对象，从而降低 GC 频次。
别指望 JVM 优化尾递归
Java 编译器和 HotSpot 虚拟机不支持尾调用优化（TCO）。即使你把递归写成尾递归形式（如 return fiboTail(n-1, acc * n)），每次调用仍会新建栈帧，不会复用。这意味着：
- 栈深度 = 递归层数，10万层就大概率栈溢出（默认-Xss 1MB 仅支持约 1–2 万层）
- 栈帧里存的局部变量、参数虽小，但大量栈帧叠加也会间接增加 GC 扫描压力（尤其当栈中引用了堆对象时）
- 不要试图靠“写成尾递归”来省 GC——它根本没被 JVM 识别为可优化结构
减少堆压力：避开递归中频繁创建对象
很多递归实现会在每层生成新对象（如 List、String、临时数组），这些对象全进堆，很快触发 Young GC。典型例子是递归深克隆、树遍历构造新节点等。
- 改用可复用的缓冲区，比如预分配一个
StringBuilder或对象池，避免每层 new 一个 - 对只读遍历类递归（如查找、校验），尽量不 new 中间容器，用索引/引用传递代替复制
- 归并排序等算法中，避免每层都 new 辅助数组；可提前分配一个全局临时数组，在递归中复用
绕过栈限制：用显式栈 + 循环替代递归
这是最可靠、JVM 友好的方式。把递归逻辑“翻译”成 while 循环 + 自定义栈（如 ArrayDeque 或 Stack），控制内存分配节奏：
- 栈空间从线程私有栈转到堆上，受 -Xmx 管理，不再受限于 -Xss
- 你可以精确控制何时创建/丢弃中间对象，配合 try-with-resources 或手动 null 掉引用，帮助 GC 更早回收
- 例如树的后序遍历：用一个栈存节点+状态标记（未访问/左已处理/右已处理），比递归调用清晰且可控
辅助手段：调参与监控
虽然不能靠 GC “救”递归，但合理配置能缓解副作用：
- 增大单线程栈大小：
-Xss2m可多撑几千层，适合已知深度可控的场景（慎用，线程多时总内存占用飙升） - 观察 GC 日志（
-Xlog:gc*），若发现 Young GC 频繁且 pause 时间长，说明递归正在堆里狂造短命对象，该重构逻辑了 - 避免在递归函数里启动新线程、打开流、创建连接——这些资源若没及时释放，会变成 GC 无法回收的“伪泄漏”
