为何堆转储大小小于JVM占用内存？两次转储差异原因咨询

让我来拆解这两个关于堆转储的常见困惑，都是Java开发者排查内存问题时经常遇到的情况：

这本质是因为堆转储只记录了堆内存的一部分内容，而JVM的总内存占用远不止堆这一块，具体原因分这几点：

• JVM内存结构不止堆：JVM的进程总内存包含堆（Heap）、元空间（Metaspace，替代永久代）、线程栈（Thread Stacks）、直接内存（Direct Memory）、JVM自身的运行时数据等。堆转储只会抓取堆里的对象数据，其他区域的内存完全不会被包含，所以文件大小肯定比JVM整体占用的内存小。
• 只保留存活对象：默认情况下，堆转储工具（比如jvisualvm、jmap）只会转储当前存活的对象——那些已经被GC标记为可回收但还没来得及清理的对象、或者从未被使用过的堆空闲空间，都不会被写入转储文件。比如你配置了2GB最大堆，但实际只有1.2GB是存活对象，那转储文件大小就会接近1.2GB，而非2GB。
• 工具的压缩优化：大多数堆转储格式（比如HPROF）会对数据做压缩处理，进一步缩小文件体积。比如jmap生成的转储文件，会用ZLIB压缩存储，磁盘占用会比堆内存活对象的实际内存更小。

这种情况大概率和GC的触发时机或者转储时的工具选项有关，结合你说的内存泄漏场景，最可能的原因是：

• 转储前是否触发了Full GC：jvisualvm在抓取堆转储时，有一个可选设置是“在堆转储前执行GC”（部分版本默认开启，部分需要手动勾选）。如果第一次转储时没触发GC，那转储文件会包含所有当前堆里的对象——包括泄漏的对象，以及大量临时缓存、软引用对象、未被清理的可回收对象，所以大小接近1.5GB；而第二次转储时触发了Full GC，这些可回收对象被清理，只剩下真正泄漏的核心对象（比如某个持有大量无用引用的缓存类，但实际对象体积不大），所以转储文件就会骤降到100MB以内。
• 两次转储之间自动触发了Full GC：如果两次转储间隔期间，JVM因为堆内存不足自动触发了Full GC，同样会清理掉大部分非泄漏的对象，此时再转储，就只剩下泄漏的对象，文件自然变小。
• 工具选项误操作：比如第一次选择了“完整堆转储”，而第二次不小心选了“堆摘要”或者仅转储特定区域的轻量模式，但这种情况比较少见，jvisualvm默认都是完整转储。
• 应用状态变化：两次转储之间，应用执行了大对象释放操作（比如手动清空了某个缓存池、重启了部分业务模块），导致堆内存活对象急剧减少，虽然内存泄漏依然存在，但泄漏的对象占比很小，所以转储文件体积大幅下降。

内容的提问来源于stack exchange，提问作者Anjan Baradwaj