与使用百分比相比，堆大小出乎意料地大答案

【问题标题】：Unexpectedly large heap size in comparison to % used与使用百分比相比，堆大小出乎意料地大
【发布时间】：2011-07-22 18:49:04
【问题描述】：

有一个内存分配问题需要您的帮助。我们在顶部分析了我们的一些服务，我们注意到它们的 RES 值约为 1.8GB，据我了解，这意味着它们当时保留了 1.8GB 的内存。如果我们刚刚启动它们会很好（它们基本上是从缓存中读取，进行处理，然后推送到另一个缓存）但是在 CPU 密集型处理完成后我们仍然看到这个，我们想知道它是否意味着某些东西没有像我们预期的那样被 GC 处理。

我们使用以下参数运行程序：-Xms256m -Xmx3096m，据我了解，这意味着初始堆大小为 256，最大堆大小为 3096。

现在我期望看到的是堆最初会根据需要增长，然后在内存被释放时根据需要缩小（尽管这可能是我的第一个错误）。我们实际看到的 jvisualvm 如下：

3 分钟内：已用堆为 1GB，堆大小为 2GB
5 分钟后：我们已经完成了处理，所以使用的堆急剧下降到接近足够的 zilch，但只有堆大小降至约 1.5GB
7 分钟 ->：实时时间定期处理，使用的堆只有100-200MB左右，堆大小但保持不变大约 1.7GB。

我的问题是，为什么我的堆没有像我预期的那样缩小？这不是在抢夺 linux 盒子上其他进程的宝贵内存吗？如果是这样，我该如何解决？我们有时确实会看到内存不足错误，并且这些进程被分配了最“意外”的内存大小，我认为最好从它们开始。

干杯，戴夫。

（~请原谅可能对JVM内存调整缺乏了解！）

【问题讨论】：

也许给盒子分配更多的交换。由于这些页面中有许多未被使用，因此内核可以将它们分页而不会造成垃圾。其他进程应该适合常驻内存。

标签： java linux jvm heap-memory

【解决方案1】：

您可能希望查看this answer 关于调整堆扩展和收缩的信息。默认情况下，JVM 在缩小堆方面并不太激进。此外，如果堆在很长一段时间内有足够的可用空间，它不会触发 GC，我认为这是唯一考虑收缩它的时间。

理想情况下，您可以将最大值配置为一个值，该值可以为您的应用程序在满负载下提供足够的空间，但如果它始终处于全部使用状态，那么操作系统性能可以接受。为了可预测性和潜在的更好性能，将最小值设置为最大值并不少见（我没有任何可以参考的东西）。

【讨论】：

感谢 WhiteFang。我认为是时候看看更激进的堆收缩了。
我想知道的另一件事是，这种事情依赖于操作系统吗？ Linux 会以与 Windows 等不同的方式处理内存/堆问题吗？
在大多数情况下，我相信操作系统对内存/堆调整无关紧要。我确信在操作系统细节方面存在细微差别，但 JVM 通常被设计为表现相同。 Solaris 往往有一些额外的旋钮，但我怀疑它会有多大帮助。

【解决方案2】：

我没有完整的答案，但是a similar question has come up before。从前面的讨论中，您应该调查-XX:MaxHeapFreeRatio= 作为您的调整参数，以强制将堆释放回操作系统。有documentation here，我相信默认值允许JVM拥有大量未使用的堆。

【讨论】：

【解决方案3】：

好吧，GC 并不总是在你思考的时候运行，它并不总是收集合格的东西。如果它几乎用完堆空间，它也可能只开始从旧代空间收集对象（因为从旧代收集通常会涉及一个停止世界的收集，GC试图避免它直到它真的需要做它）。

【讨论】：

【解决方案4】：

也许您可以尝试使用 TPTP、visualvm 或 JProbe（商业，但可以试用）进行一些分析，以了解究竟发生了什么。

另一个需要注意的是文件处理程序；我没有详细信息，但我的一位同事几年前遇到了一个由打开许多文件的进程引起的堆饱和问题，并发现每次他打开一个文件时，都会在本机堆中分配一个 4kb 缓冲区，在处理结束时释放。我希望这个相当模糊的迹象可能会有所帮助......

【讨论】：

谢谢 zim - 但我已经用 visualvm 浏览过它，这就是我在原始问题中得到数字的方式。