超出了GC开销限制

PRK*_*PRK 93 java garbage-collection jvm

JVM用于抛出'java.lang.OutOfMemoryError:超出GC开销限制'的采样时间是多少?我知道你可以用参数GCTimeLimit和GCHeapFreeLimit来控制98%和2%,但是采样时间是多少?

Edw*_*uck 82

来自Java SE 6 HotSpot [tm]虚拟机垃圾收集调整

下列

过多的GC时间和OutOfMemoryError

如果在垃圾收集中花费了太多时间,则并发收集器将抛出OutOfMemoryError:如果在垃圾收集中花费了超过98%的总时间并且恢复了少于2%的堆,则将抛出OutOfMemoryError.此功能旨在防止应用程序长时间运行,同时由于堆太小而很少或没有进度.如有必要,可以通过在命令行中添加选项-XX:-UseGCOverheadLimit来禁用此功能.

该策略与并行收集器中的策略相同,只是执行并发收集所花费的时间不计入98%的时间限制.换句话说,只有在应用程序停止时执行的集合才会计入过多的GC时间.此类集合通常是由于并发模式失败或显式收集请求(例如,对System.gc()的调用).

与进一步向下的通道相结合

使用RMI分布式垃圾收集(DGC)时,最常遇到的显式垃圾收集使用之一.使用RMI的应用程序是指其他虚拟机中的对象.在没有偶尔收集本地堆的情况下,无法在这些分布式应用程序中收集垃圾,因此RMI会定期强制执行完整收集.可以使用属性控制这些集合的频率.例如,

java -Dsun.rmi.dgc.client.gcInterval=3600000
Run Code Online (Sandbox Code Playgroud)

-Dsun.rmi.dgc.server.gcInterval=3600000 每小时指定一次显式收集,而不是每分钟一次的默认速率.但是,这也可能导致某些物体需要更长的时间才能回收.如果不希望DGC活动的时间性上限,则可以将这些属性设置为与Long.MAX_VALUE一样高,以使显式集合之间的时间有效无限.

似乎暗示确定98%的评估期是一分钟,但可以在Sun的JVM上配置正确的定义.

当然,其他解释也是可能的.

  • RMI分布式垃圾收集是与常规垃圾收集无关的活动.所以我不知道你怎么能推断出你刚刚做了什么. (5认同)
  • 推论不完美甚至不正确,这就是为什么"似乎暗示"被用来代替"暗示".如果你同意这样的观察结果:如果Sun的人们在确定RMI的垃圾收集间隔时使用了一分钟,那么并发收集中的收集时间只会在主程序停止时累计计算,并且会有一点信念的飞跃,然后赔率很高,98%是在一分钟内收集的.这是一个神奇的数字,但一分钟是一个神奇的数字,通常用于3.5分钟. (2认同)