答案是重试节奏失控与对象分配失控共同引发堆内存抖动。需通过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 事件，按堆栈分组排序：
- 聚焦出现在
doRetry()、executeWithRetry()、retryLoop()等方法下的高频分配 - 检查这些方法里是否重复创建
JSONObject、String、byte[]、HttpEntity等短生命周期对象 - 特别注意 JSON 序列化调用（如
objectMapper.writeValueAsString()）是否在每次重试中执行
堵住高频对象生成点
不追求零对象，而要让对象生成节奏可控、可复用：
- 将请求体提前序列化为
byte[]或复用ByteBuffer，避免每次重试都走一遍 JSON 序列化 - 使用
ThreadLocal<objectmapper></objectmapper>或静态共享实例，禁止在重试循环内 new ObjectMapper - 把重试参数（如超时、重试次数）封装成不可变对象复用，而非每次构造新对象
- 若用 OkHttp/Retrofit，复用
RequestBody和Request实例，避免重复构建
调重试策略防止雪崩式分配
指数退避必须带下限，否则初始重试太快仍会打满 TLAB：
- 设基础延迟
base = 50ms，第 n 次重试延时为min(100ms, 50 * 2^n) - 加最大重试次数限制（如 ≤ 3 次），避免无限循环放大压力
- 重试前做轻量级健康检查（如连接池可用连接数、上游响应码缓存），失败则跳过本次重试
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
