java内存泄漏问题排查和JVM调优

Java语言本身支持垃圾自动回收，在日常编程中我们几乎没有关注过对象回收的问题。解决内存泄漏可能停留在八股文上。今天分享一次项目中内存泄漏的排查流程到最终解决。

java自带了强大的命令行工具

工具	核心功能	主要应用场景	关键命令/示例
`jcmd`	多功能诊断：一个强大的"瑞士军刀"，可执行丰富的诊断命令，涵盖JVM状态查询、内存、线程、GC控制等。	综合诊断与运维：获取完整JVM信息（参数、属性）、动态控制（触发GC、开启JFR）、生成线程/堆转储。	`jcmd <pid> VM.flags`（查看JVM参数） `jcmd <pid> Thread.print`（生成线程转储） `jcmd <pid> GC.heap_dump`（生成堆转储）
`jmap`	堆内存分析：专用于Java堆内存（Heap Memory）的直方图统计和堆转储（Heap Dump）文件生成。	深度内存分析：排查内存泄漏、分析堆内对象分布、生成堆转储文件供MAT等工具深度分析。	`jmap -histo:live <pid>`（存活对象直方图） `jmap -dump:live,format=b,file=heap.hprof <pid>`（生成堆转储）
`jstat`	JVM统计监控：持续监控JVM各种运行时指标，特别是垃圾回收（GC）相关数据和类加载信息。	实时性能监控：监控GC行为（频率、耗时）、各内存区使用率、类加载/卸载情况，用于性能调优。	`jstat -gcutil <pid> <interval> <count>`（GC情况摘要） `jstat -gc <pid> 1000 5`（GC详情，每秒1次共5次）

Java垃圾回收算法

Java垃圾回收算法，分代垃圾回收算法

新生代：复制算法
老年代：标记-清除算法和标记-整理算法

排查思路

在解决问题的时候，先了解下我们项目JVM参数信息.

js 复制代码

jcmd <pid> VM.flags
-XX:CICompilerCount=15 -XX:InitialHeapSize=1031798784 -XX:MaxHeapSize=16489906176 -XX:MaxNewSize=5496635392 -XX:MinHeapDeltaBytes=524288 -XX:NewSize=343932928 -XX:OldSize=687865856 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseFastUnorderedTimeStamps -XX:+UseParallelGC

第一种情况：

项目运行在linux服务器上，进行压测，内存以肉眼可见的速度上升。使用top命令查看进程占用内存情况。

这里主要关注下RES 进程当前实际使用的、未被换出到交换空间（swap out）的物理内存。包含堆内存、非堆内存、堆外内存等。如果RES值持续上升，堆内存保持稳定，说明堆外内存在上升。

这个时候开始考虑使用jmap获取堆转存储。分析那些对象产生的泄漏。

常见的内存泄漏，

HashMap 、队列、线程池、websocket等资源没有正确的释放，另外一种是我们的程序调用了native方法，但没有释放资源。

发现泄漏后，最直接的办法生成jvm对象快照。生成堆转储文件，

内存分析工具

MAT（Memory Analyzer Tool） ：最常用的堆分析工具，支持自动检测泄漏嫌疑人（Leak Suspects）

泄漏嫌疑直接能看到使用websocket相关操作导致的

关键分析步骤：

识别 "可疑大对象" ：
- 在 MAT 中查看 "Histogram"（直方图），按 "Retained Heap"（对象被回收后可释放的内存）排序，找出占用内存前几名的类（如某业务 POJO、集合类）。
- 关注 "Shallow Heap"（对象本身大小）小但 "Retained Heap" 大的对象（通常是集合，持有大量子对象引用）。
追溯引用链（支配树 / 引用树） ：
- 对可疑对象右键选择 "Merge Shortest Paths to GC Roots"（排除弱引用 / 软引用等可被 GC 自动回收的引用类型），查看谁在 "强引用" 该对象。
- 核心是找到 "根对象"（如静态变量、线程对象、类加载器），这些对象不会被 GC 回收，若其引用链中包含本应释放的对象，则导致泄漏。
例：若发现大量User对象被HashMap持有，且HashMap是UserCache类的静态变量，而UserCache未设置过期清理逻辑，则可定位为 "静态缓存未释放" 导致的泄漏。