1. 初识jmap内存快照的瑞士军刀凌晨三点手机突然响起刺耳的报警声——线上服务出现OOM内存溢出异常。作为工程师这时候你需要一把能快速解剖JVM内存的手术刀而jmap正是这样的利器。这个JDK自带的小工具能在不重启服务的情况下帮你抓取内存的瞬间状态。我第一次用jmap是在五年前的一个电商大促夜。当时秒杀系统突然卡死通过jmap导出的堆转储文件我们迅速定位到是Redis连接泄漏导致的对象堆积。从那时起jmap就成了我排查内存问题的首选工具。它的核心能力主要有三方面生成堆转储快照heap dump就像给内存拍X光片记录所有对象的分布情况统计堆内存使用展示各类对象的内存占用排行榜查看类加载信息了解哪些类被加载由哪个ClassLoader负责# 基础命令格式 jmap [option] pid2. 生成堆转储文件的两种姿势2.1 手动生成dump文件当系统出现内存异常时第一时间保存现场至关重要。jmap的-dump命令能生成二进制堆转储文件# 转储整个堆包含死亡对象 jmap -dump:formatb,fileheap.hprof 12345 # 只转储存活对象生产推荐 jmap -dump:live,formatb,fileheap_live.hprof 12345这里有个实际案例某次支付系统频繁Full GC我们用以下命令抓取内存快照jmap -dump:live,formatb,file/tmp/payment_heap.hprof pgrep -f payment-service生成的文件可以用MATMemory Analyzer Tool或JVisualVM分析。记得在测试环境复现问题时对比不同时间点的dump文件能更清晰看出内存增长趋势。2.2 自动dump机制对于突发性OOM推荐配置JVM参数自动生成dump-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/path/to/dumps/曾经有个社交APP的推荐服务每天凌晨3点准时OOM。我们加上这些参数后第二天就拿到了案发现场的证据——原来是定时任务加载的推荐模型没有及时释放。注意自动dump只触发在OOM时对于内存泄漏但尚未溢出的场景仍需手动触发3. 内存分布分析的实战技巧3.1 堆内存全景图-heapjmap -heap 12345这个命令会输出堆内存的配置和使用情况比如下面这个真实案例的输出片段Attaching to process ID 12345, please wait... Debugger attached successfully. Server compiler detected. JVM version is 25.201-b09 Heap Configuration: MinHeapFreeRatio 40 MaxHeapFreeRatio 70 MaxHeapSize 2147483648 (2048.0MB) NewSize 536870912 (512.0MB) MaxNewSize 536870912 (512.0MB) OldSize 5439488 (5.1875MB) NewRatio 2 SurvivorRatio 8 MetaspaceSize 21807104 (20.796875MB) CompressedClassSpaceSize 1073741824 (1024.0MB) MaxMetaspaceSize 17592186044415 MB Heap Usage: PS Young Generation Eden Space: capacity 429522944 (409.625MB) used 429496728 (409.5999984741211MB) free 26216 (0.02500152587890625MB) 99.9939% used From Space: capacity 536870912 (512.0MB) used 536870912 (512.0MB) free 0 (0.0MB) 100.0% used To Space: capacity 536870912 (512.0MB) used 0 (0.0MB) free 536870912 (512.0MB) 0.0% used PS Old Generation capacity 1431830528 (1365.5MB) used 1431830528 (1365.5MB) free 0 (0.0MB) 100.0% used从输出可以看出Eden区已占用99.99%Survivor区全部占满老年代也100%占用说明存在严重的内存问题整个堆配置2GB但新生代和老年代比例可能不合理3.2 对象统计直方图-histo# 统计所有对象 jmap -histo 12345 | head -20 # 只统计存活对象推荐 jmap -histo:live 12345 | head -20某次排查日志服务的内存问题我们发现num #instances #bytes class name ---------------------------------------------- 1: 2589344 1424078720 [B 2: 1294672 31072128 java.util.HashMap$Node 3: 647336 15536064 java.lang.String 4: 323668 7768032 java.util.ArrayList[B代表byte数组占用了1.3GB内存进一步分析发现是日志缓存没有设置上限。4. 高级用法与避坑指南4.1 安全点Safepoint的影响jmap工作时需要所有线程进入安全点。如果某个线程长时间不进入安全点比如执行死循环会导致jmap卡住。这时候可以使用-F参数强制dump可能丢失部分数据先用jstack查看线程状态对于Linux系统可以考虑使用gcorejsadebugd组合4.2 与jstat的黄金组合jmap适合拍静态照片而jstat则像动态心电图# 每5秒打印一次GC情况 jstat -gcutil 12345 5000我曾用这个组合发现过一个典型案例老年代使用率通过jstat看到持续上升而通过jmap发现是缓存没有设置过期时间。4.3 生产环境注意事项谨慎使用live选项会触发Full GC高峰期可能引起停顿控制dump频率大堆8G的dump可能耗时几分钟文件存储位置确保磁盘空间足够至少是堆大小的1.5倍权限管理生产环境通常需要sudo权限5. 从数据到解决方案的闭环拿到堆转储文件只是开始真正的价值在于分析。常见内存问题的特征内存泄漏某个类的实例数异常多通过GC Roots分析引用链找到意外存活的对象内存溢出大对象直接占满内存比如大数组检查-Xmx设置是否合理优化案例某次分析发现JSON解析过程中创建的char[]占用了300MB通过引入对象池内存消耗降低了40%。最后分享一个实用脚本它会在内存超过阈值时自动dump#!/bin/bash PID$1 THRESHOLD80 while true; do USAGE$(jstat -gcutil $PID | awk {print $4}) if (( $(echo $USAGE $THRESHOLD | bc -l) )); then TIMESTAMP$(date %Y%m%d_%H%M%S) jmap -dump:live,formatb,fileheap_${TIMESTAMP}.hprof $PID break fi sleep 30 done记住jmap不是银弹。对于分布式系统还需要结合APM工具如Arthas进行全链路分析。但掌握好这个基础工具能让你在内存问题的迷雾中快速找到方向。
JVM监控及诊断工具命令行篇之jmap实战：从内存快照到线上问题定位
1. 初识jmap内存快照的瑞士军刀凌晨三点手机突然响起刺耳的报警声——线上服务出现OOM内存溢出异常。作为工程师这时候你需要一把能快速解剖JVM内存的手术刀而jmap正是这样的利器。这个JDK自带的小工具能在不重启服务的情况下帮你抓取内存的瞬间状态。我第一次用jmap是在五年前的一个电商大促夜。当时秒杀系统突然卡死通过jmap导出的堆转储文件我们迅速定位到是Redis连接泄漏导致的对象堆积。从那时起jmap就成了我排查内存问题的首选工具。它的核心能力主要有三方面生成堆转储快照heap dump就像给内存拍X光片记录所有对象的分布情况统计堆内存使用展示各类对象的内存占用排行榜查看类加载信息了解哪些类被加载由哪个ClassLoader负责# 基础命令格式 jmap [option] pid2. 生成堆转储文件的两种姿势2.1 手动生成dump文件当系统出现内存异常时第一时间保存现场至关重要。jmap的-dump命令能生成二进制堆转储文件# 转储整个堆包含死亡对象 jmap -dump:formatb,fileheap.hprof 12345 # 只转储存活对象生产推荐 jmap -dump:live,formatb,fileheap_live.hprof 12345这里有个实际案例某次支付系统频繁Full GC我们用以下命令抓取内存快照jmap -dump:live,formatb,file/tmp/payment_heap.hprof pgrep -f payment-service生成的文件可以用MATMemory Analyzer Tool或JVisualVM分析。记得在测试环境复现问题时对比不同时间点的dump文件能更清晰看出内存增长趋势。2.2 自动dump机制对于突发性OOM推荐配置JVM参数自动生成dump-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/path/to/dumps/曾经有个社交APP的推荐服务每天凌晨3点准时OOM。我们加上这些参数后第二天就拿到了案发现场的证据——原来是定时任务加载的推荐模型没有及时释放。注意自动dump只触发在OOM时对于内存泄漏但尚未溢出的场景仍需手动触发3. 内存分布分析的实战技巧3.1 堆内存全景图-heapjmap -heap 12345这个命令会输出堆内存的配置和使用情况比如下面这个真实案例的输出片段Attaching to process ID 12345, please wait... Debugger attached successfully. Server compiler detected. JVM version is 25.201-b09 Heap Configuration: MinHeapFreeRatio 40 MaxHeapFreeRatio 70 MaxHeapSize 2147483648 (2048.0MB) NewSize 536870912 (512.0MB) MaxNewSize 536870912 (512.0MB) OldSize 5439488 (5.1875MB) NewRatio 2 SurvivorRatio 8 MetaspaceSize 21807104 (20.796875MB) CompressedClassSpaceSize 1073741824 (1024.0MB) MaxMetaspaceSize 17592186044415 MB Heap Usage: PS Young Generation Eden Space: capacity 429522944 (409.625MB) used 429496728 (409.5999984741211MB) free 26216 (0.02500152587890625MB) 99.9939% used From Space: capacity 536870912 (512.0MB) used 536870912 (512.0MB) free 0 (0.0MB) 100.0% used To Space: capacity 536870912 (512.0MB) used 0 (0.0MB) free 536870912 (512.0MB) 0.0% used PS Old Generation capacity 1431830528 (1365.5MB) used 1431830528 (1365.5MB) free 0 (0.0MB) 100.0% used从输出可以看出Eden区已占用99.99%Survivor区全部占满老年代也100%占用说明存在严重的内存问题整个堆配置2GB但新生代和老年代比例可能不合理3.2 对象统计直方图-histo# 统计所有对象 jmap -histo 12345 | head -20 # 只统计存活对象推荐 jmap -histo:live 12345 | head -20某次排查日志服务的内存问题我们发现num #instances #bytes class name ---------------------------------------------- 1: 2589344 1424078720 [B 2: 1294672 31072128 java.util.HashMap$Node 3: 647336 15536064 java.lang.String 4: 323668 7768032 java.util.ArrayList[B代表byte数组占用了1.3GB内存进一步分析发现是日志缓存没有设置上限。4. 高级用法与避坑指南4.1 安全点Safepoint的影响jmap工作时需要所有线程进入安全点。如果某个线程长时间不进入安全点比如执行死循环会导致jmap卡住。这时候可以使用-F参数强制dump可能丢失部分数据先用jstack查看线程状态对于Linux系统可以考虑使用gcorejsadebugd组合4.2 与jstat的黄金组合jmap适合拍静态照片而jstat则像动态心电图# 每5秒打印一次GC情况 jstat -gcutil 12345 5000我曾用这个组合发现过一个典型案例老年代使用率通过jstat看到持续上升而通过jmap发现是缓存没有设置过期时间。4.3 生产环境注意事项谨慎使用live选项会触发Full GC高峰期可能引起停顿控制dump频率大堆8G的dump可能耗时几分钟文件存储位置确保磁盘空间足够至少是堆大小的1.5倍权限管理生产环境通常需要sudo权限5. 从数据到解决方案的闭环拿到堆转储文件只是开始真正的价值在于分析。常见内存问题的特征内存泄漏某个类的实例数异常多通过GC Roots分析引用链找到意外存活的对象内存溢出大对象直接占满内存比如大数组检查-Xmx设置是否合理优化案例某次分析发现JSON解析过程中创建的char[]占用了300MB通过引入对象池内存消耗降低了40%。最后分享一个实用脚本它会在内存超过阈值时自动dump#!/bin/bash PID$1 THRESHOLD80 while true; do USAGE$(jstat -gcutil $PID | awk {print $4}) if (( $(echo $USAGE $THRESHOLD | bc -l) )); then TIMESTAMP$(date %Y%m%d_%H%M%S) jmap -dump:live,formatb,fileheap_${TIMESTAMP}.hprof $PID break fi sleep 30 done记住jmap不是银弹。对于分布式系统还需要结合APM工具如Arthas进行全链路分析。但掌握好这个基础工具能让你在内存问题的迷雾中快速找到方向。
