这是栈溢出而非堆内存泄漏，因重试中无限嵌套包装异常导致调用栈持续增长，触发StackOverflowError；需限制重试次数、避免异常cause链传递、统一异常处理出口。
这不是堆内存泄漏，而是典型的栈溢出（StackOverflowError），根源在于重试逻辑中反复包装异常、无限递归构造新异常对象，导致每个重试层都追加一层完整的调用栈——栈帧持续压入，最终超出JVM线程栈默认容量（通常1MB左右）。
确认是否为栈溢出而非堆泄漏
先看错误日志关键词：
- 出现
java.lang.StackOverflowError，且堆栈深度达数百甚至上千行 → 是栈溢出 - 堆栈中重复出现相同方法名（如
retryWithFallback()、wrapException()、doInvoke()）并逐层缩进 → 表明异常被多层嵌套包装 - 没有
OutOfMemoryError: Java heap space或 GC 频繁迹象 → 可排除堆泄漏主因
检查重试链中异常包装的典型错误模式
重点排查以下代码结构：
- 每次重试都用
new RuntimeException(e)或new CustomException("retry #" + i, e)包裹上层异常，而未限制重试层数或清理原始栈 - 在
RetryTemplate的recoveryCallback中又调用自身重试方法，形成隐式递归 - Feign/RestTemplate 的
ErrorDecoder或ResponseErrorHandler内部主动 new 异常并传入原异常作为 cause，且该 handler 被多次代理增强（如被 Hystrix、Resilience4j、自定义 AOP 层层拦截） - 自定义重试注解（如
@Retryable）配合 AOP 实现时，在环绕通知中捕获异常后不终止流程，反而再次触发代理链
快速定位包裹层数与源头
无需重启，直接通过运行时诊断缩小范围：
- 在重试入口或异常处理器开头加日志：
log.debug("Stack depth: {}", Thread.currentThread().getStackTrace().length);，观察数值是否随重试次数线性增长（如从200→400→600） - 捕获
StackOverflowError时打印其栈顶10行：Arrays.stream(e.getStackTrace()).limit(10).forEach(log::error);，识别最外层包装类 - 用
jstack <pid></pid>抓取线程快照，搜索关键词Retry|Exception|wrap|cause，查看某一线程栈中是否密集出现同一段重试逻辑
修复关键动作：切断异常嵌套链
不是简单改 catch 块，而是阻断“异常→重试→新异常→再重试”的正反馈循环：
-
禁止无节制 cause 链传递：重试时若需保留原始错误信息，改用字段存储（如
retryCount、originalCode），而非构造嵌套Throwable -
设置硬性重试上限：Spring Retry 的
maxAttempts=3、Resilience4j 的maxAttempts=3必须显式配置，避免默认值过大或无限重试 -
统一异常处理出口：所有重试逻辑最终应汇聚到一个标准化的
handleFailure()方法，该方法只记录原始异常消息和状态码，不 new 新异常 -
禁用冗余代理增强：检查是否同时启用了 Feign 的
ErrorDecoder+ Spring Retry + 自定义 AOP retry 切面 → 保留一层即可，其余关闭
本质上这是控制流设计问题，不是内存管理问题。栈空间有限，每一次“优雅地包装异常”都在悄悄消耗它。不复杂但容易忽略。
