JVM 和 GC 調整 - 沒有 Full GC 的理論

Question

我有兩種類型的對象的大規模應用程序：長壽命（緩存）和短壽命（請求-過程-響應）。 理論上，用這種類型的應用，我覺得可以配置 Young vs Old 空間，所以 Old 空間消耗是恆定的，導致沒有 Full GC。

我已經更改了 newSize-maxNewSize 參數，但是，舊堆繼續上升，直到 Full GC。 每次 Full GC 后，消耗下降到 20%（緩存占 20%）。 出於某種原因，我的對象進入了舊空間。 我有兩個懷疑為什么要搬到舊空間：

• 根據這篇文章： http://chaoticjava.com/posts/gc-tips-and-memory-leaks/如果您分配了大對象，那些 go 直接分配給舊空間。 這是真的嗎，如果是，是否有 JVM 選項參數可以設置年輕空間的 object 大小閾值？

• 如果我正確理解了該過程，則對象會在 To-From 生存部分之間切換，然后再移至舊部分。 是否有參數可以設置在移動到舊空間之前要在 To 和 From 之間進行多少次切換？

還有其他提示嗎？

謝謝，阿馬爾

Answer 1

聽起來您的幸存者空間確實不夠大。 您需要使它們足夠大，以至於不需要收集任何對象。 object 只進出幸存者空間一次。

如果您正在分配大對象，您可以使用 Object 池來避免對它們進行 GC。 您是否考慮過將 object 池也用於您的請求/處理/響應數據？ 例如，一個簡單的方法是使用 ThreadLocal。

您是否嘗試過 G1 收集器，該收集器旨在逐步收集您的所有 memory 並減少完整 GC 的大命中。

Answer 2

你確定老年代的增長只是沒有緩存對象嗎？ 除非您的緩存是固定的並且永遠不會更改，否則您將不斷地添加它。 由於已經進入老年代的對象從該緩存中過期，它們將留在 memory 直到下一次完整的 GC。

並發標記掃描收集器完全消除了完整 GC 的長時間停頓，我的運氣要好得多。 這需要一些調整，並且可能因應用程序而異。 以下是我們用來運行 24GB 64 位 JVM 的方法，其 GC 暫停時間為亞秒級，同時通過大型緩存每秒處理 100 多個頁面請求：

-Xms24g -Xmx24g -XX:+UseCompressedOops -XX:NewRatio=4 -XX:SurvivorRatio=8    
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+DisableExplicitGC  
-XX:+UseCMSInitiatingOccupancyOnly -XX:+CMSClassUnloadingEnabled  
-XX:+CMSScavengeBeforeRemark -XX:CMSInitiatingOccupancyFraction=68

Answer 3

是否有參數可以設置在移動到舊空間之前要在 To 和 From 之間進行多少次切換？

是的， -XX:MaxTenuringThreshold

此開關確定對象在提升到老一代之前在“From”和“To”Survivor 空間之間跳躍的次數。 Java 6 的最大值為 15，早期 JDK 的最大值為 31。 並行收集器的默認值為 15，CMS 收集器的默認值為 4 。

來自 Sun JVM GC 文檔，

使用 -XX:MaxTenuringThreshold=0 將在年輕代收集中幸存的 object 立即移動到終身代。

正如你想做的相反，如果你沒有設置這個值，它將是默認值，這足以決定 object 是否需要將 go 轉換為Old - 正如@Peter所說，幸存者是大到足以容納這些物體。

您的 SurvivorRatio 設置為多少？ 你的總堆是多少？

Answer 4

Object 生命周期特征在這里起着至關重要的作用。重要的調整旋鈕是幸存者空間的大小、任期閾值和年輕代的大小。 從戰略上講，我們希望對象在年輕一代中死亡，因此如果次要 collections 之間有足夠的差距，很多 object 將在年輕一代中死亡。 此外，我們可以配置任期閾值，以便對象在幸存者空間中保留所需數量的 collections。

由於我們在幸存者空間中保留了大量活動對象，並不斷將它們從一個空間復制到另一個空間以進行多次次要 GC，因此增加了次要 GC 的成本。

保持較大的年輕代自然會增加連續次要 collections 之間的差距，並為對象提供更多死亡時間。

可以通過試驗這些變量來達到適當的平衡，以減少 object 對老一代的提升，並考慮可接受的年輕一代暫停