通过dashboard识别内存异常趋势后，用heapdump抓取多份快照，再用mat对比分析“objects added”及gc roots路径，可准确定位泄漏对象，无需重启或复现。

直接用 dashboard 看整体趋势，再用 heapdump 抓快照分析，就能在线定位生产环境的内存异动，不用重启、不依赖复现。

dashboard 快速识别异常模式

执行 dashboard 后重点关注三类指标：

• 老年代（g1_old_gen 或 old）使用率持续攀升，且 Full GC 后回收极少，说明长期对象在堆积
• 堆内存（heap）已用值缓慢但稳定上涨，没有明显回落周期，大概率存在泄漏
• 线程数（thread count）同步增长，尤其 daemon 线程持续增加，可能伴随 ThreadLocal 或未关闭资源

注意：不要只看单次结果，建议每 1–2 分钟执行一次，连续观察 5–10 次，确认是否为稳定上升趋势而非偶发抖动。

heapdump 抓取关键时间点快照

确认异常趋势后，立即执行：

• heapdump arthas-output/dump-1.hprof —— 记录当前状态
• 等待 3–5 分钟（视增长速度调整），再执行 heapdump arthas-output/dump-2.hprof
• 必要时补第三份，如怀疑泄漏速度慢，可间隔 10–15 分钟再抓一份

生成的 .hprof 文件需下载到本地，用 Eclipse MAT 打开。优先查看 “Leak Suspects” 报告，它会自动标出最可疑的几组对象及其保留集大小。

对比分析锁定泄漏对象

在 MAT 中打开两个快照，用 “Compare with Heap Dump” 功能做差异分析：

• 筛选 “Objects added” 列，找数量增长最剧烈的类（比如 com.example.OrderCacheEntry 从 1.2 万涨到 4.8 万）
• 对高增长类右键 → “Merge Shortest Paths to GC Roots” → 勾选 “exclude weak/soft references”，看谁在强引用持有它们
• 若发现是静态集合（如 ConcurrentHashMap）、未清理的监听器或缓存未过期，基本就是泄漏源头

不需要完整读代码，MAT 显示的 GC Roots 路径通常能直接指向配置类、初始化方法或注册逻辑。

注意事项与避坑点

实际操作中容易忽略的关键细节：

• heapdump 会触发一次 Full GC，生产环境建议避开高峰时段，或先用 memory 确认老年代压力未达临界
• Arthas 自身需要内存，若目标 JVM 已严重内存不足，attach 可能失败；可临时加 -XX:MaxMetaspaceSize=512m 防止元空间挤占堆空间
• dashboard 中 nonheap 区（尤其是 metaspace）持续上涨，可能是动态生成类过多（如反复 CGLIB 代理），和堆泄漏无关，需单独排查