gc日志是诊断内存泄漏与回收健康的核心依据，需重点观察频率异常（young gc间隔骤缩）、晋升异常（老年代使用量持续上涨）、回收无效（full gc后老年代占用几乎不变）三类信号。
JVM内存回收和内存泄漏检测不是两个孤立环节，而是一体两面的实战过程：回收机制是否健康，直接反映在泄漏是否存在；而泄漏是否发生，又必须通过回收行为和内存变化趋势来判断。关键不在于堆 dump 一抓就灵，而在于建立“观测→假设→验证→定位”的闭环路径。
看懂 GC 日志与实时指标是第一道防线
GC 日志是 JVM 自己写的“运行日记”，比任何工具都原始、真实。启用 -XX:+PrintGCDetails -XX:+PrintGCDateStamps 并重定向到文件后，重点观察三类信号：
- 频率异常：年轻代 GC（Young GC）间隔从秒级缩短到毫秒级，说明对象存活率高或分配速率暴增
- 晋升异常：每次 Young GC 后老年代使用量持续上涨（OU 字段递增），且 Full GC 频次同步上升，大概率存在长生命周期对象堆积
- 回收无效：Full GC 后老年代占用（OU）几乎不变，或仅下降极小比例（如
配合 jstat -gc
用对工具链，避免“dump 了也白 dump”
堆转储（heap dump）本身不解决问题，解读方式决定成败。不同阶段选不同工具：
-
紧急现场取证：用 jmap -dump:format=b,file=heap.hprof
快速抓取，全程无侵入；若进程已卡死，可加 -F 强制执行 - 初筛泄漏嫌疑：用 Eclipse MAT 打开 dump，直接点 “Leak Suspects” 报告——它会自动计算支配树（Dominator Tree）并标出占用内存 Top N 的对象及其 GC Root 路径
- 深挖引用链：在 MAT 的 “Dominator Tree” 中右键目标对象 → “Path to GC Roots” → 选择 “with all references”，逐层展开，重点识别静态变量、缓存容器、未注销监听器、ThreadLocal Map 等典型泄漏源
注意：不要依赖 “Histogram” 单看类实例数量，要结合“Retained Heap”列——它表示该对象及其所有可达子对象独占的内存，这才是泄漏影响的真实量级。
识别四类高频泄漏模式，直击根源
80% 的堆泄漏集中在以下四类结构，排查时可优先聚焦：
-
静态集合类：如 public static Map
cache = new HashMap(); 缺少清理逻辑，导致对象永久驻留。MAT 中表现为 HashMap 或 ConcurrentHashMap 实例的 Retained Heap 异常巨大 - 未注销的监听器/回调：GUI 组件、Spring EventListener、Netty ChannelHandler 注册后未 remove，使被监听对象（如 Activity、Service、Bean）无法释放
- ThreadLocal 泄漏：在线程池场景下，ThreadLocal 变量未调用 remove()，导致线程复用时旧值持续累积。MAT 中可见 ThreadLocalMap$Entry 数组膨胀，Key 为 null 但 Value 仍强引用着大对象
- 未关闭的资源持有者：如 Connection、InputStream、ByteBuffer.allocateDirect() 返回的直接内存缓冲区，虽不在堆内，但其 Cleaner 对象若被阻塞，会间接拖垮堆内存（因元空间或直接内存耗尽触发 Full GC）
验证修复效果，闭环才算完成
改完代码不能只测功能，必须验证内存行为是否回归正常：
- 重启应用，用 jstat 观察 OU 是否稳定在低位（如
- 模拟相同业务流量，对比修复前后 Full GC 次数与耗时（jstat -gc 输出中 FGC 和 FGCT 字段）
- 若条件允许，用 Arthas 的 memory 命令动态监控指定类实例数变化，确认新增对象能被及时回收
真正有效的修复，是让 GC 行为恢复“年轻代频繁回收、老年代长期平稳”的健康节奏，而不是靠加大 -Xmx 临时掩盖问题。
