超出 GC 开销限制

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

以下

Excessive GC Time and 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 上通过正确的定义进行配置。

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

---