【JVM深度解析】第15篇：JVM配置优化案例二：内存泄漏定位与修复（MAT分析全流程）

摘要内存泄漏是 Java 应用最隐蔽的性能杀手——它不会让你的应用立刻崩溃但会让它慢慢死去堆内存持续增长GC 越来越频繁最终 OOM。某物流追踪系统的内存从 2GB 增长到 8GB 只用了 48 小时每次 Full GC 后老年代不降反升。本案例完整记录使用Eclipse MATMemory Analyzer Tool进行堆转储分析的全流程从 dump 触发、到支配树分析、再到可疑泄漏点定位最终发现是一个静态 HashMap 缓存未清理的经典问题。修复后内存稳定在 3GBFull GC 后老年代大幅下降。一、问题背景1.1 业务场景某物流公司的实时追踪系统使用 JDK 11 Spring Boot 2.7部署在 16GB 内存的服务器上使用 CMS GC。系统负责实时接收 GPS 设备上报的位置数据延迟要求 5 秒。1.2 故障现象监控数据48 小时 Day 1, 00:00 - 堆使用2.1GB/16GBOld Gen: 1.2GB/8GB Day 1, 12:00 - 堆使用4.5GB/16GBOld Gen: 3.8GB/8GB ← 48小时内翻倍 Day 2, 00:00 - 堆使用7.8GB/16GBOld Gen: 7.2GB/8GB ← 接近上限 Day 2, 06:00 - Full GC OOM GC 日志特征 - Minor GC 正常每 30 秒一次 - Full GC 后老年代内存不降反升危险信号 - 老年代从 Full GC 前的 7GB 降到 6.8GB只回收了 200MB1.3 内存增长曲线内存泄漏的典型曲线 ┌──────────────────────────────────────────────────────────────────┐ │ │ │ 内存(GB) │ │ ↑ │ │ 8 │ _______________ │ │ 7 │ ____- │ │ 6 │ ___- │ │ 5 │ ___- │ │ 4 │ ____- │ │ 5 │ _____ │ │ 4 │ ____- │ │ 3 │ ____- │ │ 2 │ __- │ │ 1 │ │ │ └──────────────────────────────────────────────────────→ │ │ Day1 Day1 Day1 Day2 Day2 Day2 Day2 │ │ 00:00 06:00 12:00 00:00 06:00 12:00 18:00 │ │ │ │ 关键特征持续上升不随 GC 回落 │ │ 正常 GC 曲线锯齿状峰值不会持续升高 │ │ │ └──────────────────────────────────────────────────────────────────┘二、问题分析2.1 初步诊断# 确认内存泄漏特征$ jstat-gcutil123455000# 多次采样间隔 5 秒观察 Old Gen 是否持续上升S0 S1 E O M YGC YGCT FGC FGCT0.008.5045.0072.5085.2015612.342345.6758.010.0012.3050.0078.3085.2015712.452345.6758.12← O 持续上升0.0015.8055.0084.2085.2015812.562345.6758.23← O 持续上升0.0018.2060.0089.8085.2015912.672345.6758.34← 危险# 分析# - Old Gen 使用率从 72.5% 持续上升到 89.8%短短 15 秒# - Full GC 次数不变23次说明还没触发 Full GC# - 内存持续增长 确认内存泄漏2.2 堆转储准备# 方案一手动触发堆转储在 OOM 之前手动做$ jcmd12345GC.heap_dump /tmp/heap_leak_$(date%Y%m%d_%H%M%S).hprof# 方案二设置自动触发配置 JVM 参数# 在启动脚本中添加# -XX:HeapDumpOnOutOfMemoryError# -XX:HeapDumpPath/var/log/heapdump.hprof# -XX:HeapDumpBeforeFullGC ← Full GC 前也 dump# 等待 dump 完成约 2-5 分钟取决于堆大小ls-lh/tmp/heap_leak_*.hprof2.3 MAT 分析流程下载 Eclipse MAThttps://www.eclipse.org/mat/downloads.php# 启动 MATGUI 模式./MemoryAnalyzer-XX:UseG1GC/tmp/heap_leak_20260315_030000.hprof# 或使用命令行生成报告./ParseHeapDump.sh /tmp/heap_leak.hprof\org.eclipse.mat.api:suspects\org.eclipse.mat.api:top_components\org.eclipse.mat.api:overview三、MAT 分析实战3.1 Overview 概览打开堆转储文件后首先看 OverviewLeak Suspects 饼图分析 ┌──────────────────────────────────────────────────────────────────┐ │ Histogram 排名前10 │ ├──────────────────────────────────────────────────────────────────┤ │ Class Name │ Objects │ Shallow Heap │ Retain Heap│ │ ----------------------------------------------------------------│ │ char[] │ 2,345,678 │ 987,654,321 │ 2,147,XXX │ │ java.lang.String │ 1,234,567 │ 98,765,XXX │ 1,023,XXX │ │ java.util.HashMap$Node │ 890,123 │ 42,XXX,XXX │ 890,XXX │ │ java.util.HashMap │ 56,789 │ 2,XXX,XXX │ 780,XXX │ ← 可疑 │ com.example.GpsLocation │ 345,678 │ 55,XXX,XXX │ 456,XXX │ ← 大量对象 │ com.example.CacheEntry │ 89,012 │ 14,XXX,XXX │ 123,XXX │ └──────────────────────────────────────────────────────────────────┘ # 发现可疑点 # 1. HashMap 和 HashMap.Node 数量异常多 # 2. GpsLocation 对象有 34.5 万个还在堆里正常应该被回收3.2 Dominator Tree支配树支配树是 MAT 最强大的功能——它找出哪些对象支配了大量内存Dominator Tree 分析按 Retained Heap 排序 ┌──────────────────────────────────────────────────────────────────┐ │ Path To GC Roots: com.example.LocationCache.cache │ ├──────────────────────────────────────────────────────────────────┤ │ │ │ com.example.LocationCache.cache ←──────┐ │ │ └─ HashMap (89,012 entries) │ │ │ └─ HashMap.Node[89,012] │ Retained: 780MB │ │ └─ CacheEntry (GpsLocation) │ │ │ │ │ 问题LocationCache 是一个 static 缓存不断添加数据但从未清理 │ │ │ └──────────────────────────────────────────────────────────────────┘3.3 Unreachable Objects 排除Histogram → Group by Class Loader → 查看是否有 ClassLoader 泄漏 通常需要排除 - 已卸载的类加载器的对象 - 虚引用/弱引用持有的对象正常会被回收 - 字符串常量池中的字符串3.4 定位泄漏根因// MAT 中Go To功能查看 LocationCache 类实例// 发现类定义publicclassLocationCache{// 泄漏根因静态 HashMap容量无上限privatestaticfinalMapString,GpsLocationcachenewHashMap();publicvoidupdate(StringdeviceId,GpsLocationlocation){cache.put(deviceId,location);// 只进不出}// 缺少清理方法// public void clearOldEntries() { ... } ← 不存在}四、问题代码分析4.1 原始问题代码ComponentpublicclassLocationCache{// 问题 1静态缓存生命周期 JVM 生命周期privatestaticfinalMapString,GpsLocationcachenewHashMap();// 问题 2只往里加不清理publicvoidupdateLocation(StringdeviceId,GpsLocationlocation){cache.put(deviceId,location);}// 问题 3没有 TTL没有大小限制publicGpsLocationgetLocation(StringdeviceId){returncache.get(deviceId);}}4.2 使用方代码ServicepublicclassGpsTrackingService{AutowiredprivateLocationCachecache;// 模拟调用每秒处理 1000 个 GPS 设备数据publicvoidprocessGpsData(ListGpsDatadataList){for(GpsDatadata:dataList){GpsLocationlocationnewGpsLocation(data);// 每条数据都往缓存里塞cache.updateLocation(data.getDeviceId(),location);}}}// 问题每天 86400 秒 * 1000 设备 8600 万条数据// HashMap 不断膨胀 → 内存泄漏五、解决方案5.1 方案一使用带 TTL 的缓存框架// 推荐使用 Caffeine高性能缓存库ComponentpublicclassLocationCache{// Caffeine支持 TTL、最大容量、淘汰策略privatefinalCacheString,GpsLocationcacheCaffeine.newBuilder().maximumSize(100_000)// 最大 10 万条.expireAfterWrite(Duration.ofMinutes(30))// 30 分钟 TTL.recordStats()// 记录统计.build();publicvoidupdateLocation(StringdeviceId,GpsLocationlocation){cache.put(deviceId,location);}publicOptionalGpsLocationgetLocation(StringdeviceId){returnOptional.ofNullable(cache.getIfPresent(deviceId));}// 暴露统计信息publicCacheStatsgetStats(){returncache.stats();}}5.2 方案二使用 WeakHashMap适合短生命周期缓存// WeakHashMap当 key 没有其他引用时可被 GC 回收ComponentpublicclassLocationCacheV2{// 适用场景缓存项的生命周期与业务对象关联privatefinalMapDevice,GpsLocationcachenewWeakHashMap();publicvoidupdateLocation(Devicedevice,GpsLocationlocation){cache.put(device,location);}}5.3 完整依赖!-- Maven 依赖 --dependencygroupIdcom.github.ben-manes.caffeine/groupIdartifactIdcaffeine/artifactIdversion3.1.8/version/dependency六、效果验证6.1 修复前后对比修复后 72 小时监控 Day 1, 00:00 - 堆使用2.1GB/16GBOld Gen: 1.1GB/8GB Day 1, 12:00 - 堆使用2.8GB/16GBOld Gen: 1.8GB/8GB ← 正常波动 Day 2, 00:00 - 堆使用2.5GB/16GBOld Gen: 1.5GB/8GB ← GC 后回落 Day 2, 12:00 - 堆使用2.9GB/16GBOld Gen: 1.9GB/8GB ← 稳定 GC 日志特征修复后 - Full GC 后老年代从 7GB 降到 1.8GB回收 5.2GB← 正常 - 内存使用呈现健康的锯齿状不再持续上升6.2 Caffeine 统计监控// 定期输出缓存统计Scheduled(fixedRate60000)publicvoidlogCacheStats(){CacheStatsstatscache.stats();log.info(Cache stats: hitRate{}, evictions{}, size{},stats.hitRate(),stats.evictionCount(),cache.estimatedSize());}// 日志输出示例// Cache stats: hitRate0.85, evictions1234, size67890// - 85% 命中率良好// - 每分钟约 1234 次淘汰正常 TTL 淘汰// - 缓存大小稳定在 6-7 万bounded七、经验总结7.1 内存泄漏常见模式┌──────────────────────────────────────────────────────────────────┐ │ Java 内存泄漏 Top 5 │ ├──────────────────────────────────────────────────────────────────┤ │ │ │ 1. 静态集合持有对象最常见 │ │ 解决使用带 TTL 或大小限制的缓存 │ │ │ │ 2. 监听器/回调未注销 │ │ 解决Spring PreDestroy 清理或使用 WeakReference │ │ │ │ 3. ThreadLocal 未清理 │ │ 解决在线程池中使用 ThreadLocal务必在 finally 中 remove() │ │ │ │ 4. 内部类持有外部引用 │ │ 解决使用静态内部类或使用 WeakReference │ │ │ │ 5. 数据库连接/流未关闭 │ │ 解决try-with-resources或使用连接池管理 │ │ │ └──────────────────────────────────────────────────────────────────┘7.2 MAT 使用技巧MAT 快捷键和技巧 1. CtrlShiftM → 按包名分组 2. CtrlF → 搜索对象 3. Right Click → Path To GC Roots → 查看根因 4. Java Basics → Thread Details → 查看线程持有 5. OQL → SQL 风格查询对象SELECT * FROM java.util.HashMap WHERE size() 1000系列导航上一篇【JVM深度解析】第14篇JVM配置优化案例一Full GC频繁导致服务不可用下一篇【JVM深度解析】第16篇JVM配置优化案例三CPU 100%排查线程死循环系列目录JVM深度解析系列全集参考资料Eclipse MAT DocumentationCaffeine Cache GitHubJava Memory Leaks: Tools, Causes, and PatternsDiagnosing Memory Leaks with MAT