超出GC开销限制

Question

JVM用于抛出'java.lang.OutOfMemoryError：超出GC开销限制'的采样时间是什么？ 我知道你可以通过参数GCTimeLimit和GCHeapFreeLimit控制98％和2％，但最新的采样时间是多少？

Answer 1

从Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning

以下

过多的GC时间和OutOfMemoryError异常

并发收集器将抛出一个OutOfMemoryError如果太多 的时间被消耗在垃圾收集上：如果超过98在垃圾回收中花费的总时间的百分比和回收的堆中不到2％，会抛出OutOfMemoryError。此功能 旨在防止应用程序在延长时间内运行一段时间，同时几乎不进行任何操作，因为堆太小而无法使用。如有必要，可以通过将 选件 -XX：-UseGCOverheadLimit添加到命令行来禁用此功能。

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

与通道进一步向下

一个明确的垃圾收集 与RMIS分布式垃圾收集（DGC）发生的最常见的用途相结合。 使用RMI的应用程序引用其他虚拟机中的对象。 这些分布式应用程序无法收集垃圾，因为偶尔会收集本地堆，因此RMI会定期强制收集全部收集文件 。这些集合的频率可以通过属性来控制 。例如，

java -Dsun.rmi.dgc.client.gcInterval=3600000 

-Dsun.rmi.dgc.server.gcInterval=3600000每小时，而不是每一次微小 的违约率指定一次明确的集合。但是，这也可能导致一些对象花费更长的时间来回收 。如果 不需要DGC 活动的及时性的上限，则可以将这些属性设置为与Long.MAX_VALUE 一样高，以使明确收集之间的时间实际上是无限的。

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

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