Java 超出 GC 开销限制
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/4371505/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
GC overhead limit exceeded
提问by PRK
What is the sampling time JVM uses to throw 'java.lang.OutOfMemoryError : GC overhead limit exceeded'? I know you can control 98% and 2% with parameters GCTimeLimit and GCHeapFreeLimit but whats the sampling time?
JVM 用于抛出“java.lang.OutOfMemoryError : GC 开销限制超出”的采样时间是多少？我知道您可以使用参数 GCTimeLimit 和 GCHeapFreeLimit 控制 98% 和 2%，但是采样时间是多少？
回答by Edwin Buck
From Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning
来自Java SE 6 HotSpot[tm] 虚拟机垃圾收集调优
the following
下列
Excessive GC Time and OutOfMemoryError
The concurrent collector will throw an OutOfMemoryError if too much time is being spent in garbage collection: if more than 98% of the total time is spent in garbage collection and less than 2% of the heap is recovered, an OutOfMemoryError will be thrown. This feature is designed to prevent applications from running for an extended period of time while making little or no progress because the heap is too small. If necessary, this feature can be disabled by adding the option -XX:-UseGCOverheadLimit to the command line.
The policy is the same as that in the parallel collector, except that time spent performing concurrent collections is not counted toward the 98% time limit. In other words, only collections performed while the application is stopped count toward excessive GC time. Such collections are typically due to a concurrent mode failure or an explicit collection request (e.g., a call to System.gc()).
GC 时间过长和 OutOfMemoryError
如果垃圾收集花费了太多时间，并发收集器将抛出 OutOfMemoryError：如果超过 98% 的总时间花费在垃圾收集上，而回收的堆不到 2%，则会抛出 OutOfMemoryError。此功能旨在防止应用程序长时间运行而由于堆太小而进展甚微或没有进展。如有必要，可以通过在命令行中添加选项 -XX:-UseGCOverheadLimit 来禁用此功能。
该策略与并行收集器中的策略相同，只是执行并发收集所花费的时间不计入 98% 的时间限制。换句话说，只有在应用程序停止时执行的收集才会计入过多的 GC 时间。此类收集通常是由于并发模式失败或显式收集请求（例如，对 System.gc() 的调用）。
in conjunction with a passage further down
与进一步向下的通道相结合
One of the most commonly encountered uses of explicit garbage collection occurs with RMIs distributed garbage collection (DGC). Applications using RMI refer to objects in other virtual machines. Garbage cannot be collected in these distributed applications without occasionally collection the local heap, so RMI forces full collections periodically. The frequency of these collections can be controlled with properties. For example,
java -Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000specifies explicit collection once per hour instead of the default rate of once per minute. However, this may also cause some objects to take much longer to be reclaimed. These properties can be set as high as Long.MAX_VALUE to make the time between explicit collections effectively infinite, if there is no desire for an upper bound on the timeliness of DGC activity.
显式垃圾回收最常遇到的用途之一是 RMI 分布式垃圾回收 (DGC)。使用 RMI 的应用程序引用其他虚拟机中的对象。如果不偶尔收集本地堆，就无法在这些分布式应用程序中收集垃圾，因此 RMI 会定期强制执行完全收集。这些集合的频率可以通过属性来控制。例如，
java -Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000指定每小时显式收集一次，而不是每分钟一次的默认速率。但是，这也可能导致某些对象需要更长时间才能回收。如果不需要 DGC 活动的及时性上限，则可以将这些属性设置为 Long.MAX_VALUE，以使显式集合之间的时间有效地无限。
Seems to imply that the evaluation period for determining the 98% is one minute long, but it might be configurable on Sun's JVM with the correct define.
似乎暗示确定 98% 的评估期为一分钟，但它可能可以在 Sun 的 JVM 上使用正确的定义进行配置。
Of course, other interpretations are possible.
当然，其他解释也是可能的。
