堆转储分析是定位java内存问题的起点，通过支配者树、直方图和gc roots路径聚焦关键对象，结合jcmd或oom自动触发获取可靠快照，并需在分析前验证文件大小与格式，最终将发现映射回代码缺陷如静态集合泄漏、循环创建临时对象或大对象强引用。
堆转储分析不是调优的“附加项”，而是定位内存问题的起点。它不直接修改JVM参数，但能告诉你哪些参数该调、哪段代码该改——比如发现某类对象持续堆积，就说明新生代大小或GC策略可能不合理；看到大量缓存对象长期驻留老年代，就提示需要检查缓存淘汰逻辑或调整老年代阈值。
怎么获取一份靠谱的堆转储
关键不在“能不能生成”，而在“生成时机是否反映真实问题”：
- 生产环境优先用 jcmd
GC.heap_dump /path/to/dump.hprof ：它由JVM内部触发，停顿短、兼容性好，比jmap更轻量 - 自动捕获必须配 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/dumps/：路径要可写，且建议加时间戳命名（如 -XX:HeapDumpPath=/data/dumps/heap_%p_%t.hprof）
- 避免在高负载时用 jmap -dump:live：它会先触发Full GC，可能加剧卡顿，仅限低峰期或测试环境使用
打开文件前先做三件事
一份几百MB甚至几GB的.hprof文件，别急着扔进MAT等工具里硬啃：
- 用 ls -lh 看大小——明显偏小（如4GB）要考虑分片或筛选后再分析
- 用 file dump.hprof 确认格式是否为HPROF binary —— 防止误用文本工具打开二进制文件
- 用 VisualVM 快速加载，看“Classes”页签中实例数TOP10的类——如果某个业务类实例达百万级，基本可锁定问题方向
重点看什么，而不是看全貌
真正有效的分析，从来不是翻遍所有对象，而是聚焦三个视图：
- 支配者树（Dominator Tree）：找内存“大头”。排序后看“Retained Heap”列，排第一的对象往往就是泄漏源头或缓存容器，点开它看直接引用了哪些子对象
- 直方图（Histogram）：查数量异常。右键某类 → “List objects” → “with outgoing references”，再按“Referent”排序，能快速识别被静态集合或ThreadLocal强持有的对象
- GC Roots到可疑对象的路径（Path to GC Roots）：追引用链。选一个典型实例 → 右键 → “Path to GC Roots” → 勾选“with all references”，重点看是否经过 static、final、Thread、ClassLoader 等不易释放的根节点
常见模式对应典型代码问题
分析结果要落回代码，不能只停留在工具界面：
- 静态集合持续增长 → 检查 static Map/List 是否缺少清理机制，尤其注意监听器注册后未反注册
- 大量相同类实例 + 每个占用小但总量巨大 → 看是否在循环中创建了不必要的临时对象（如String拼接、JSON序列化中间对象）
- 单个对象Retained Heap超百MB → 关注 大缓存、未关闭的流、Base64编码的图片/文件，检查是否本该用软引用或弱引用却用了强引用
