答案是重试节奏失控与对象分配失控共同引发堆内存抖动。需通过GC日志确认G1 Evacuation Pause(young)是否密集且间隔100–500ms，结合JFR定位doRetry()等方法下高频分配，并优化JSON序列化复用、指数退避带下限及重试次数限制。
这类问题本质是“重试节奏失控 + 对象分配失控”共同引发的堆内存抖动，不是单纯内存泄漏，也不是配置不足，而是业务逻辑与JVM资源调度不匹配。
看GC日志确认抖动特征
打开 GC 日志（-Xlog:gc*:file=gc.log:time,tags,level），重点观察：
- 是否密集出现 G1 Evacuation Pause (young)，且间隔稳定在 100–500ms
- 每次 young GC 后存活对象比例是否异常升高（说明大量小对象逃逸到老年代）
- 是否存在连续多次 young GC 但回收量极低（TLAB 分配失败频繁触发 GC）
抓堆栈定位重试源头
用 JFR（Java Flight Recorder）采集 60 秒运行数据，筛选 Object Allocation in New TLAB 事件，按堆栈分组排序：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 聚焦出现在
doRetry()、executeWithRetry()、retryLoop()等方法下的高频分配 - 检查这些方法里是否重复创建
JSONObject、String、byte[]、HttpEntity等短生命周期对象 - 特别注意 JSON 序列化调用（如
objectMapper.writeValueAsString()）是否在每次重试中执行
堵住高频对象生成点
不追求零对象，而要让对象生成节奏可控、可复用：
立即学习“Java免费学习笔记（深入）”；
- 将请求体提前序列化为
byte[]或复用ByteBuffer，避免每次重试都走一遍 JSON 序列化 - 使用
ThreadLocal<ObjectMapper>或静态共享实例，禁止在重试循环内 new ObjectMapper - 把重试参数（如超时、重试次数）封装成不可变对象复用，而非每次构造新对象
- 若用 OkHttp/Retrofit，复用
RequestBody和Request实例，避免重复构建
调重试策略防止雪崩式分配
指数退避必须带下限，否则初始重试太快仍会打满 TLAB：
- 设基础延迟
base = 50ms，第 n 次重试延时为min(100ms, 50 * 2^n) - 加最大重试次数限制（如 ≤ 3 次），避免无限循环放大压力
- 重试前做轻量级健康检查（如连接池可用连接数、上游响应码缓存），失败则跳过本次重试
