什么是大堆的近似最坏情况垃圾收集持续时间

Question

我需要一个关于完全垃圾收集的最大时间的经验法则。其动机是能够区分错误的JVM进程和GC下的进程。

假设我有一个常规的通用服务器硬件，HotSpot JVM 8，堆大小为20G-40G，没有设置特定的GC和内存选项。 GC完成的合理时限是多少？是5分钟，20分钟还是长达数小时？

更新： 我的应用程序是一个处理大数据结构的内存密集型脱机工作。我根本不需要调整GC。如果知道此限制，则10秒和10分钟暂停是机器人。

Answer 1

很难量化GC“应该”花多长时间，因为它取决于许多因素：

• 堆有多大。
• 如何完整堆;即运行GC时垃圾与非垃圾的比率。
• 有多少指针/引用遍历。
• 您正在使用哪种GC。
• 这是否是次要的“新一代”系列，主要的“老一代系列”或“完整”系列。当低延迟收集器无法跟上垃圾生成速度时，最后一个通常由回退收集器执行。
• 是否有物理＆lt; - ＆gt;虚拟内存捶打发生。

有几种病理情况会导致过多的GC时间：

• 如果堆几乎已满，GC会使用越来越多的时间来回收最后一点可用空间。

• 如果您的堆大于可用的物理内存，则可能会进入虚拟内存“颠簸”行为。这在主要或完整GC期间最为明显。

如果您确实需要选择一个号码，我建议您使用一个“感觉”正确的号码，并将其作为配置参数，以便轻松调整。此外，打开GC日志记录并查看那里报告的典型 GC时间。 （特别是当服务器负载很高时。）

Answer 2

首先，gc暂停时间在大多数情况下都计入毫秒。如果gc需要多于一个秒，我认为您的应用无论如何都必须进行调整。

然后正如评论所说， gc暂停时间取决于应用程序的特征。因此，如果您需要关于应用程序完全垃圾收集的最大时间的经验法则，我建议您收集 gc.log 和制作统计数据，然后你会知道在一个糟糕的gc中暂停时间有多长。

Answer 3

对于延迟无关紧要的批量作业，有比暂停时间更好的措施：

a）收集垃圾的MB /时间/ cpu核心<​​/ p>

低收集率通常表示一些病态情况，如交换，透明的大页面整合或GC中的一些边缘情况，例如正在扫描的大量参考阵列。

b）应用程序吞吐量 - 应用程序代码中花费的时间与在GC中花费的时间之间的比率。

如果不经常发生长GC，那么它们不是一个大问题。

可以通过GCViewer

运行GC日志来获取两者

Answer 4

我的建议是： 1.配置JVM参数并打开GC日志，检查GC日志，您将看到GC需要多长时间 2. GC不会是分钟，我看到大约13秒的暂停时间，客户受到了非常严重的影响。