JDK 自带工具 jmap：Java 堆内存分析与排查实战

查看堆中对象统计信息

如果想了解哪些对象占用了最多内存，可以使用直方图功能：

# 查看所有对象
jmap -histo 24126
# 仅查看存活对象（会触发 Full GC，慎用）
jmap -histo:live 24126

输出结果包含实例数、内存占用和类名。在 Linux/Unix 环境下，可以通过管道命令优化展示：

# 按实例数降序排序并分页查看
jmap -histo 24126 | sort -k 2 -g -r | less
# 筛选特定包名的对象
jmap -histo 24126 | grep alibaba | sort -k 3 -g -r | less

这里要注意，[C 代表字符数组（String 底层），[B 代表字节数组，看到这类类名占比高时要留意是否涉及大量 IO 或文本处理。

生成堆转储文件

当遇到 OOM 或疑似内存泄漏时，生成堆转储文件是关键一步：

# 生成包含所有对象的转储
jmap -dump:format=b,file=/opt/heap/dump_all_24126.hprof 24126
# 生成仅包含存活对象的转储（推荐，数据更干净）
jmap -dump:live,format=b,file=/opt/heap/dump_live_24126.hprof 24126
# 应急场景：进程无响应时强制执行
jmap -F -dump:format=b,file=/opt/heap/dump_force_24126.hprof 24126

注意事项：

1. STW 风险：堆转储过程耗时与堆大小正相关，期间 JVM 会暂停应用（Stop The World），生产环境务必避开业务高峰期。
2. 磁盘空间：.hprof 文件大小接近实际使用大小，确保存储路径有足够空间。
3. 归档命名：建议按时间戳或进程 ID 命名，便于后续多版本对比。

堆转储文件的后续分析

生成的 .hprof 文件无法直接阅读，需借助专业工具：

1. MAT（Eclipse Memory Analyzer Tool）：业界主流，支持检测内存泄漏、查找大对象、分析引用链，适合复杂问题排查。
2. VisualVM：JDK 自带可视化工具，操作简洁，适合快速查看堆概况和对象统计。
3. jhat：JDK 自带命令行工具，启动 Web 服务器供浏览器查看，适合轻量级快速排查，大型文件不推荐。

内存泄漏/OOM 排查最佳实践

当应用出现内存不足或频繁 Full GC 时，建议按以下步骤操作：

1. 手动生成转储：若应用未崩溃但内存异常，手动执行 jmap -dump:live 生成文件。建议间隔 5-10 分钟多生成几份，便于对比对象变化趋势。
2. 深度分析：使用 MAT 打开文件，重点关注「Leak Suspects」（泄漏可疑点）。寻找大量存活且无业务意义的对象、长生命周期对象引用短生命周期对象，或未关闭的资源（数据库连接、文件流等）。
3. 验证修复：根据分析结果修改代码，重新部署后通过 jstat、jmap 监控内存变化。

提前配置自动生成：建议在启动参数中添加以下配置，让 JVM 在发生 OOM 时自动抓取现场：

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/opt/heap/oom_dump.hprof

这样即使进程瞬间崩溃，也能保留关键数据。

注意事项与避坑指南

1. 版本一致性：jmap 工具版本最好与目标 Java 进程一致，否则可能出现连接失败或输出异常。
2. CMS GC 慎用：在使用 CMS GC 的场景下，执行 jmap -heap 可能导致进程卡死甚至崩溃。如需获取堆状态，优先使用 jstat -gc。
3. Full GC 风险：-histo:live 和 -dump:live 都会触发 Full GC，高负载下需谨慎使用，避免影响业务可用性。
4. 权限要求：执行用户需与 Java 进程运行用户一致，否则会出现权限拒绝错误。
5. 大文件处理：对于超过 10GB 的堆文件，MAT 可能需要调整启动配置（如增加 -Xmx 参数）才能正常打开。

总结

jmap 是 Java 内存问题排查的核心工具，核心能力在于查看堆内存使用情况和生成堆转储文件。日常排查中，建议遵循'轻量优先、避开高峰'的原则。遇到 OOM 问题时，结合自动配置与手动抓取的策略，能最大程度减少故障恢复时间。