超出了GC開銷限制

Question

JVM用於拋出'java.lang.OutOfMemoryError：超出GC開銷限制'的采樣時間是多少？ 我知道您可以使用參數GCTimeLimit和GCHeapFreeLimit控制98％和2％但是采樣時間是多少？

Answer 1

來自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 

-Dsun.rmi.dgc.server.gcInterval=3600000指定每小時顯式收集一次，而不是每分鍾一次的默認速率。 但是，這也可能導致某些物體需要更長的時間才能被回收。 如果不希望DGC活動的時間性上限，則可以將這些屬性設置為Long.MAX_VALUE，以使顯式集合之間的時間有效無限。

似乎暗示確定98％的評估期是一分鍾，但可以在Sun的JVM上配置正確的定義。

當然，其他解釋也是可能的。