堆转储！=虚拟内存？答案

【问题标题】：Heap dump != virtual memory?堆转储！=虚拟内存？
【发布时间】：2015-09-25 10:29:50
【问题描述】：

不是很了解 Java，尤其是 Java 中的调试，但是在 Jenkins 中使用 Monitoring 进行堆转储，然后在 Eclipse 中使用 MAT 对其进行解码，显示使用的总内存为 169.4 MB，而在 Jenkins 中监控内存似乎经常被大量使用，并且 GC 经常运行。 -XmX 是 4G。

为什么我只有 169.4 MB 的 MAT？可能是因为在进行转储之前 Jenkins 执行了 GC？如果是这样，我可以避免看到完整的内存转储吗？

【问题讨论】：

AFAIK 转储会在之前导致 gc，或者至少 MAT 会忽略可能被 gc 处理的内容。 Jenkins 可能会在之后有资格进行 gc 的工作期间加载大量数据。顺便说一句，你如何触发转储？它是 Jenkins 的内置功能还是您通过 JConsole 或类似的方式向 JVM 发送命令？
@Thomas 转储可以从监控插件触发。有一个按钮 - 我只能这么说 :) 来自 Jenkins GUI
在这种情况下，可能是插件停止了当前作业或等待它完成（或者当前作业加载了很多数据但不再需要）。 - 我只是在这里猜测，因为我不知道那个插件。但除此之外，您是否有频繁 GC 的问题？
@Thomas 我不这么认为。使用 4G 内存，GC 大约 30 秒执行一次，耗时 1 秒。我在加载页面/控制台日志时遇到问题，但不存在网络问题，Jenkins 日志什么也没说。任何地方都没有错误，只是页面加载缓慢。即使是主节点上的系统负载也很少会超过 1（运行 64 位 RHEL，具有 4 个内核和 24 G ram 以及其他 6 个使用较少内存的 Jenkins 实例）。
@Thomas 有人说 - 在收集转储之前执行 GC ......这不是有点不对吗？如果某些东西保留了太多内存，您将如何解决内存问题？它只是被清理了，所以人们永远不会发现......我会尝试找到一些控制台命令用于没有 GC 的堆转储。

标签： java memory jenkins dump heap-dump

【解决方案1】：

理解记忆

是的，Java 堆转储和虚拟内存转储（在 Windows 上称为“崩溃转储”或“内存转储”）是不同的东西。

Java 堆转储只包含与 Java 相关的内存，即 Java 对象所在的位置。使用 MAT（如您所提到的）或 Java Heap Analysis Tool 等工具分析 Java 堆转储

（用户模式）进程的 Windows 故障转储包含所有虚拟内存，其中虚拟内存是提供内存的操作系统的术语。在 Windows 上，这是通过 VirtualAlloc 分配的所有内存。

操作系统虚拟内存将包括 Java 堆，因为 Java 只能从操作系统请求内存。

因此，在比较内存大小时，了解该工具是特定于 Java 还是通用操作系统非常重要。

在您的情况下，Monitoring 看起来很像一个通用工具，因为它处理进程列表和 CPU 时间，这似乎不是 Java 特定的。另一方面，MAT 从它的描述来看，显然是一个 Java 工具。

内存差异

那么 Java 堆大小与虚拟内存大小可以相差多少？

很多：

加载的 EXE/DLL 占用虚拟内存，但不占用 Java 堆
本机代码（例如通过 JNI）使用的内存记入虚拟内存，但不记入 Java 堆
Java 从操作系统请求但尚未被 Java 使用的内存肯定算作虚拟内存，但从 Java 的角度来看可以报告为“空闲”。

【讨论】：

感谢您的好回答。只是一个小的更正：在这种情况下，monitoring 实际上是监控 Jenkins JVM 而不是操作系统。

【解决方案2】：

显然，收集堆转储的工具会执行 GC 以减小转储的大小。由于可 GC 的事物不应产生 OOM，因此其目的是发现内存泄漏而不是解决内存使用问题。

【讨论】：

【解决方案3】：

VM 请求虚拟内存来存储各种数据。 VM 然后分配一些内存来存储变量（即堆）、本机代码（不是堆）、保留一些尚未使用的内存。因此，虚拟内存严格大于堆。鉴于您可以编写简单的无限递归（堆几乎与虚拟内存一样大）或在 hello world 程序中加载大型 dll（堆比虚拟内存小得多），因此堆和虚拟内存之间没有任何明确的相关性）。

【讨论】：