定位内存回收异常需四步：先看GC日志确认回收类型与趋势；再抓堆快照用MAT分析内存占用对象；接着审查代码中短命对象与资源泄漏；最后依代际关系合理调参，避免盲目扩堆。

频繁触发内存回收，尤其是 Full GC，本质是 JVM 堆内存压力失衡的外在表现。关键不在于“怎么压低 GC 次数”，而在于定位哪一环导致对象无法及时释放或空间分配不合理。下面从实操角度分四步讲清楚。

看 GC 日志，确认是哪类回收在拖累系统

先打开详细日志，这是所有分析的起点：

• 启动参数加上：-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log
• 重点关注：每次 GC 类型（Minor/Major/Full）、耗时、各区域回收前后大小（尤其 Eden 使用率、老年代占用趋势、晋升量）
• 如果发现 Minor GC 频繁但每次只回收一点点，说明 Eden 太小或对象存活率高；如果 Minor GC 不多但老年代缓慢上涨、突然触发 Full GC，大概率是对象过早晋升或老年代空间不足

抓堆快照，查谁占着内存不放

GC 日志只能告诉你“发生了什么”，堆快照才能告诉你“是谁干的”：

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

• 用 jmap -dump:format=b,file=heap.hprof 抓取运行中堆镜像
• 用 MAT（Memory Analyzer Tool）打开，查看 “Leak Suspects Report” 和 “Dominator Tree”
• 重点盯三类对象：静态集合（如 static Map 无清理）、未注销的监听器/回调、缓存未设淘汰策略、大数组或字符串（如日志拼接、Base64 解码结果）

查代码和对象生命周期，识别短命对象风暴

很多 Full GC 的根因不在堆大小，而在代码层制造了大量本不该存在的临时对象：

• 循环内反复创建新对象（如 new SimpleDateFormat()、new ArrayList()）
• 字符串拼接不用 StringBuilder，尤其在循环里用 + 拼接
• 流式操作（如 Stream.filter/map）产生中间对象，或未关闭 InputStream/Connection 等资源，间接导致关联对象无法释放
• 检查是否误用强引用缓存，比如把 HTTP 请求体、用户会话数据长期存在 static Map 中

调参数前先理清代际关系，避免盲目加大堆

参数调优不是“堆越大越好”，而是让对象在合适的地方待够时间：

• 观察日志中的晋升速率（Promotion Rate），如果每次 Minor GC 都有大量对象直接进老年代，可能是 Survivor 区太小 → 调 -XX:SurvivorRatio（如从 8 改为 6）
• 年轻代总占比偏低（如 -XX:NewRatio=6 表示年轻代仅占堆 1/7），容易导致 Eden 快满 → 可适当提高年轻代比例
• 老年代持续增长且碎片化严重，考虑换 G1 收集器：-XX:+UseG1GC -XX:MaxGCPauseMillis=200，它能更主动地并发清理老年代
• 元空间（Metaspace）暴涨？说明动态生成类过多（如频繁反射、CGLIB 代理）→ 加 -XX:MaxMetaspaceSize 并检查类加载逻辑