本地内存小于堆转储文件大小时如何开展Java堆转储分析

原分析方案触发OOM的核心原因 #

• 你之前执行的jhad -J-d64 -J-mx25g存在笔误，实际对应JDK自带的jhat分析命令，给进程申请25G堆内存的配置在32G内存的服务器上很容易触发内存不足：32G物理内存需要预留4-6G给系统内核、后台进程、磁盘页缓存，实际可用内存本来就达不到25G；再加上jhat的解析逻辑会全量加载所有堆对象到内存中，解析完成后的实际内存占用往往比21G的原始转储文件体积高60%以上，就算堆配置值足够，进程也会因为内存超限被系统OOM killer直接终止。

适配当前硬件条件的可行分析方案 #

针对jhat的有限调优 #

• 不要将jhat的堆内存配置到服务器总内存的80%以上，32G内存的服务器可配置的最大jhat堆值建议调整为18G以内，搭配G1GC降低内存碎片率，启动命令调整为jhat -J-d64 -J-Xmx18g -J-XX:+UseG1GC -parse=only，先完成初步的类直方图统计，再逐块拉取对象引用信息，避免一次性加载全量内容。
• 执行命令前先清理服务器上的残留进程、无用日志缓存，至少释放4G空闲物理内存，减少进程被OOM终止的概率。

低内存占用的专用分析工具 #

这类工具不需要将21G的转储文件全量加载进内存，支持流式扫描、按需读取，完全适配32G远程服务器+8G本地设备的硬件条件：

• Eclipse MAT 命令行模式：是目前处理大体积HPROF效率最高的工具，它的分析逻辑不需要把所有堆对象驻留在内存中，支持在服务器端运行无GUI的解析脚本，自动生成内存泄漏怀疑点、类内存占比概览、大对象列表的结构化分析报告，这类报告的体积通常只有几MB到几十MB。只需要把报告拉到本地8G内存的设备上，用MAT图形界面打开就能做细节排查，完全不需要传输21G的原始转储文件。服务器端执行的解析命令参考ParseHeapDump.sh 你的转储文件路径 org.eclipse.mat.api:suspects org.eclipse.mat.api:overview org.eclipse.mat.api:top_components，整个扫描过程的内存占用通常稳定在6-8G，远低于32G服务器的内存上限。
• JProfiler 无GUI远程分析模式：可以在远程服务器上启动无界面的分析服务端，将服务端口映射到本地后，本地客户端只拉取需要排查的对象数据片段，不会把整个21G的转储加载到本地内存中，远程服务端的运行内存占用通常在7G以内。
• 分段式HPROF扫描脚本：可以基于HPROF的文件结构做流式分段解析，先提取大数组、大对象、类内存分布的纯文本统计结果，整个过程内存占用不到2G，拿到结果后再针对异常类做定向的引用链查询，不需要全量加载文件。

关键避坑提示 #

• 不要尝试把21G的HPROF文件传到本地8G内存的设备上，不仅传输耗时久，本地也完全没有足够内存完成加载，所有初步解析步骤都在远程32G服务器上完成，本地只拉取解析后的结构化结果或定向查询的对象片段。
• 不要继续在jhat上调整更大的内存配置值，jhat本身的解析效率和内存占用控制能力都不适合20G级别的堆转储，换专用工具的分析效率会提升数倍，内存占用也会降低一个数量级。

内容的提问来源于stack exchange，提问作者Nikita Duginets