排查 JVM 内存泄漏的核心思路遵循“‌确认趋势 - 抓取快照 - 分析定位 - 修复代码‌”的标准流程。切忌一看到内存上涨就盲目调整参数首先需要区分是业务增长导致的正常内存占用还是真正的内存泄漏。以下是详细的排查步骤和方法一、 确认是否存在内存泄漏内存泄漏的典型表现是‌老年代Old Gen内存使用率随时间呈线性或阶梯式持续上升且 Full GC 后内存无法回落到正常基线。‌‌观察监控指标‌‌老年代趋势‌重点关注老年代的使用率。如果每次 Full GC 后老年代的剩余内存都比上一次多且长期不回落极大概率存在泄漏。‌Full GC 频率‌如果 Full GC 变得非常频繁但每次回收的效果很差释放内存很少说明大量对象无法被回收。‌排除干扰因素‌需排除因流量激增、缓存预热、大对象临时分配导致的暂时性内存升高。‌使用命令行工具实时监控‌‌jstat -gcutil 1000‌每秒打印一次 GC 统计信息。重点观察 OUOld Used老年代已用空间和 OCOld Capacity老年代容量。如果 OU 持续接近 OC 且 FGCFull GC 次数不断增加则疑似泄漏。‌jmap -histo:live ‌查看存活对象的直方图。对比多次执行的结果如果某些类的实例数量只增不减这些类就是嫌疑对象。二、 抓取堆内存快照Heap Dump一旦确认存在泄漏趋势需要获取堆内存的现场数据进行分析。‌自动导出推荐生产环境配置‌在启动参数中添加 -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/path/to/dump当发生 OOM 时自动生成快照。‌手动导出‌‌使用 jmap‌jmap-dump:formatb,fileheap.hprofpid注意该操作会触发 Full GC 并暂停应用STW建议在低峰期或备用节点执行。‌使用 Arthas在线诊断神器‌#1.初步检查内存概况 memory #2.生成堆转储文件 heapdump/tmp/heap.hprofArthas 的优势在于无需重启应用且对线上服务影响相对可控。三、 分析快照定位泄漏源将生成的 .hprof 文件下载到本地使用专业工具进行分析。‌常用分析工具‌‌Eclipse Memory Analyzer (MAT)‌功能最强大适合深度分析。‌JVisualVM / JConsole‌JDK 自带界面友好适合快速查看。‌Online Heap Analyzer‌如果文件过大可使用在线轻量级工具。‌MAT 分析核心步骤‌‌Leak Suspects Report‌打开 MAT 后首页通常会直接给出“泄漏嫌疑报告”指出哪些对象占用了大量内存且疑似未释放。‌Dominator Tree支配树‌按对象占用内存大小排序。找到占用内存最大的几个对象右键选择 ‌Path to GC Roots - exclude weak/soft references‌排除弱引用和软引用。‌定位引用链‌通过 GC Roots 路径你可以清晰地看到是谁哪个静态变量、哪个线程、哪个集合持有了这些对象的引用导致它们无法被回收。四、 常见内存泄漏场景与修复根据分析结果常见的泄漏点通常集中在以下四类‌静态集合无限增长‌‌现象‌static HashMap/List 等容器不断添加对象但从未移除。‌修复‌限制集合大小或使用弱引用映射如 WeakHashMap或在适当时机清理数据。‌ThreadLocal 未清理‌‌现象‌在线程池场景中ThreadLocal 设置的值在线程复用后未被清除导致对象一直依附于线程存在。‌修复‌务必在 finally 块中调用 threadLocal.remove()。‌资源未关闭‌‌现象‌数据库连接、IO 流、网络连接使用后未关闭。‌修复‌使用 try-with-resources 语法确保资源自动关闭。‌监听器/回调未注销‌‌现象‌注册了事件监听器或回调函数但在对象不再使用时未注销导致被全局事件管理器长期持有。‌修复‌在对象销毁生命周期中显式注销监听器。‌第三方库或框架 Bug‌‌案例‌如某些异步日志框架在特定配置下可能产生大量 StackTraceElement 对象堆积或 Hibernate 一级缓存未清理导致实体对象累积。‌修复‌升级版本、调整配置如限制缓存大小或联系厂商修复。五、 特殊情况Native 内存泄漏如果 Java 堆内存Heap和元空间Metaspace正常但进程整体 RSS 内存持续飙升可能是 ‌Native 内存泄漏‌。‌排查工具‌开启 -XX:NativeMemoryTrackingdetail使用 jcmd VM.native_memory detail 查看非堆内存分布。‌常见原因‌直接内存Direct Buffer、JNI 调用、线程栈过多、glibc 内存碎片等。总结排查 JVM 内存泄漏的关键在于‌“对比”‌和‌“追踪”‌‌对比‌ Full GC 前后的内存基线确认泄漏事实。‌追踪‌ 堆快照中异常增长对象的 GC Roots 引用链定位代码根源。保持定期的内存监控和合理的 GC 日志记录如 -Xlog:gc*能帮助你在问题早期发现端倪避免生产事故。