推荐的最大堆内存使用量是多少？推荐的垃圾收集时间？答案

【问题标题】：What is the recommended max level of heap memory usage? Recommended garbage collection time?推荐的最大堆内存使用量是多少？推荐的垃圾收集时间？
【发布时间】：2012-06-15 16:10:50
【问题描述】：

我最近发现我的一项服务在垃圾收集中花费了大量时间，因为最大堆大小太小。该服务在我开始之前就在那里，所以我不知道堆大小很小。如果它超过某个点，我想设置一个警报来警告我，但我也不想给它比它实际需要的更多的资源。您认为对于垃圾收集和堆使用百分比应该警惕的合理水平是多少？

我认为平均堆使用量的警报约为 85%，gc 为 100 毫秒/5 分钟。

我知道这是基于要求和硬件，但我确实在寻找一些基准或标准来做出决定。

【问题讨论】：

这完全取决于您编写的上下文和程序......推荐的堆内存使用“最大级别”和推荐的 GC 时间是尽可能少。 :)
@AlexLockwood 我认为该评论是一个答案，也是正确的答案。太糟糕了，我不能投票给你代表。
JVM 通常会在 GC 之前达到 99% 以上的堆使用率。只有在 Full GC 之后使用的百分比很重要，恕我直言，这应该是大约 30-50%。

标签： java garbage-collection heap-memory alarm

【解决方案1】：

亚历克斯洛克伍德的回答是这样的：

建议的堆内存使用和 GC 时间的“最大级别”尽可能少。

这是误导。我实际上建议相反。尝试压缩堆大小是个坏主意，因为这会导致您的应用程序更频繁地运行 GC，并且花费更少的时间（平均而言）做有用的工作。

问题基本上是这样的。当 JVM 用完空间来分配对象时，就会运行经典（非并发）GC。然后它遍历非垃圾对象，将它们复制到不同的“空间”。运行 GC 周期的处理器时间很大程度上取决于非垃圾的数量......但它实现的有用工作（它释放的空间量）与heapsize - nongarbage 成正比。因此，当您压缩堆大小时，您会减少 GC 所做的有用工作量......对于相同的处理器时间消耗。

原来的问题是这样说的：

我认为平均堆使用量的警报约为 85%，gc 为 100 毫秒/5 分钟。

在绝对级别的 GC CPU 使用率上设置监视器/警报可能没有用。 GC 时间将取决于服务器活动以及 GC 效率。您不希望每次服务器繁忙时 GC 警报都会响起。

85% 的平均堆使用率是合理的警报水平，但再次将警报设置为固定水平可能会产生过多的错误警报。

另一种方法是使用 JVM 选项设置“在 GC 中花费的时间百分比”阈值，并将其与“在 OutOfMemoryException 上杀死 JVM”选项相结合，并在服务器的启动脚本中放置一个自动重启循环.然后监视重启。

【讨论】：

我相信垃圾收集与heapsize - nongarbage成正比的说法只对了一半。我相当有信心 Java 使用混合的停止和复制 + 分代垃圾收集器，在这种情况下，这种说法并不完全准确。但话又说回来，我只是在这里吹毛求疵。除此之外，我必须同意你对亚历克斯的回答。
您混淆了您的 GC 术语。 Concurrent 与 Stop-the-world 是关于 GC 是否在后台运行。复制与标记和清除是关于正在运行的算法系列。分代是关于你是否以相同的速率 GC 整个堆，还是花更多时间收集年轻对象。
但是你是对的，现代的 Hotspot JVM 确实使用了多种策略，包括（我相信）如果没有足够的空间来容纳足够大的“to”空间，则使用 mark-and-sweep。即便如此，当您考虑压缩阶段时，工作与非垃圾量的关系更为密切。（而且我确信它必须执行标记扫描压缩，否则堆分配器必须处理空闲列表。）
我的措辞不佳。我应该更明确一点。我指的是使用复制算法的方法，同时使用分代策略来避免经常查看旧对象。我试图理解的一点是，如果内存由旧对象支配并且收集器使用分代策略，则垃圾收集所花费的时间并不总是与heapsize - nongarbage 成正比
不，你是对的。它应该是“空间大小 - 非垃圾”。但是 spacesize 与 heapssize 相关......如果您正在执行“完整”收集，则直接相关。

【解决方案2】：

这完全取决于您编写的上下文和程序。

建议的堆内存使用和 GC 时间的“最大级别”尽可能少。

【讨论】：