超出了GC开销限制

JVM抛出“ java.lang.OutOfMemoryError：超出了GC开销限制”的采样时间是多少？我知道您可以使用参数GCTimeLimit和GCHeapFreeLimit来控制98％和2％，但是采样时间是多少？

java garbage-collection jvm

— PRK
source

下列

过多的GC时间和OutOfMemoryError

如果在垃圾回收上花费了太多时间，则并发收集器将抛出OutOfMemoryError：如果在垃圾回收中花费了总时间的98％以上，而回收的堆少于2％，则将抛出OutOfMemoryError。此功能旨在防止应用程序长时间运行，而由于堆太小而几乎没有进展，甚至没有进展。如有必要，可以通过在命令行中添加选项-XX：-UseGCOverheadLimit来禁用此功能。

该策略与并行收集器中的策略相同，除了执行并发收集所花费的时间不计入98％的时间限制。换句话说，只有在应用程序停止时执行的收集才计入过多的GC时间。此类收集通常是由于并发模式故障或显式收集请求（例如，对System.gc（）的调用）引起的。

结合一段更远的地方

显式垃圾回收最常遇到的用途之一是RMI分布式垃圾回收（DGC）。使用RMI的应用程序引用其他虚拟机中的对象。如果不偶尔收集本地堆，就无法在这些分布式应用程序中收集垃圾，因此RMI会定期强制执行完整收集。这些收集的频率可以通过属性来控制。例如，
java -Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000 指定每小时一次的显式收集，而不是默认的每分钟一次的速率。但是，这也可能导致某些对象需要更长的时间才能被回收。如果不希望DGC活动的及时性达到上限，则可以将这些属性设置为Long.MAX_VALUE，以有效地使显式集合之间的时间无限长。

似乎暗示确定98％的评估周期为一分钟长，但是可以使用正确的定义在Sun的JVM上进行配置。

当然，其他解释也是可能的。

— 埃德温·巴克
source

RMI分布式垃圾收集是与常规垃圾收集无关的活动。因此，我看不出如何推断您刚刚所做的事情。

— 斯蒂芬·C 2010年

推论不是完美的甚至是正确的，这就是为什么使用“似乎暗示”而不是“暗示”的原因。如果您同意以下观点，即如果Sun公司的员工花了1分钟来确定RMI的垃圾收集间隔，那么并发收集中的收集时间只会在主程序停止时才被计算出来，这会使您产生一点信念，那么一分钟内收集到98％的几率就很好。这是一个魔术数字，但是一分钟是一个魔术数字，相比之下，通常说3.5分钟。

— Edwin Buck 2010年

@StephenC您的意思是即使我们设置-XX:+DisableExplicitGC 它也不会影响RMI相关的配置，并且系统将以参数-Dsun.rmi.dgc.server.gcInterval

— Steephen的

@Steephen-不。我不是这个意思。我说的是这句话：“似乎暗示确定98％的评估时间为一分钟长……”。并请注意，埃德温（Edwin）同意推断是“不完美的”。该推论是基于这样的假设，即实施RMI（＆DGC）的Sun人员与实施GC开销限制机制的人员紧密联系。我怀疑这两种发展实际上发生在不同的时间。请注意，该-Dsun.rmi.dgc.server.gcInterval属性自Java 1.2起就存在。

— 斯蒂芬·C

无论如何，找到此问题的真正答案的更好方法是查看OpenJDK源代码。

— 斯蒂芬·C