gc頻繁的暫停啟動

這篇文章將討論一種減少垃圾收集暫停的技術，它會延遲應用程序的延遲。 正如我幾年前所寫， 在JVM中無法禁用垃圾收集 。 但是，有一個巧妙的技巧可以用來大大減少長時間停頓的時間和頻率。

如您所知，JVM內部發生了兩個不同的GC事件，稱為次要和主要集合。 關于這些收集期間發生的事情，有很多可用的材料，因此，我將不著重于詳細描述其機制。 我只想提醒一下，在Hotspot JVM中-在次要收集期間，將收集eden和幸存者空間，在主要收集中，使用權空間也將被清理和（可能）壓縮。

如果打開GC日志記錄（例如， -XX：+ PrintGCDetails ），則會立即注意到主要集合是您應關注的集合。 一次大型垃圾收集的時間通常比一個清潔的年輕空間大幾倍。 在大型GC中，有兩個方面需要更多時間才能完成。 首先，年輕空間中的幸存者被復制到老地方。 接下來，除了清除舊版本中未使用的引用外，大多數GC算法還壓縮了舊空間，再次需要消耗寶貴的CPU周期。

在舊空間中放置許多對象也增加了從舊空間到年輕空間的引用更多的可能性。 當檢查這些表以確定年輕空間中的對象是否適合使用GC時，這會導致更大的卡片表 ，跟蹤引用并增加次要GC暫停的時間。

因此，如果我們不能關閉垃圾收集，是否可以確保這些冗長的大型GC的運行頻率降低，并且從使用權空間到Young的引用計數保持較低水平？

答案是肯定的。 甚至有一些瘋狂的配置已經完全擺脫了主要的GC。 擺脫主要的GC事件確實是一項復雜的工作，但是減少這些長時間停頓的頻率是每個部署都可以實現的目標。

我們正在考慮的策略是限制可使用的對象的數量。 例如，在典型的Web應用程序中，創建的大多數對象僅在HttpRequest期間有用。 存在并且將永遠具有更長的壽命的共享狀態，但是關鍵在于以下事實：短暫生存的對象與長期生存的共享狀態的比率非常高。

現在進行任何部署的棘手部分是了解為短期對象提供多少肘部空間，以便

• 您可以保證短期對象不會被提升為終身空間
• 您不會過度配置，從而增加了基礎架構的成本

從概念上講，做到這一點很容易。 您只需要測量在請求期間為短期對象分配的內存量，并將其與峰值加載時間相乘即可。 您將要得到的結果是您想要在eden或單個幸存者空間中容納的內存量。 這將使GC真正有效地運行，而不會意外升級為終身保有權。 從概念層面進行放大會發現一些復雜的技術問題，我將在以后的文章中介紹這些問題。

那么從這里可以得出什么結論呢？ 首先-為您的應用程序確定理想的GC配置是一項復雜的工作。 這既是壞消息，也是好消息。 不好的是–它需要您進行大量的實驗。 考慮到這一點，我們很樂意解決棘手的問題，目前正在制定實驗以進一步研究該領域。 有朝一日，在不久的將來， Plumbr能夠為您完成此任務，從而使您免于無聊的管道工作，并使您專注于當前的實際問題。

翻譯自: https://www.javacodegeeks.com/2014/10/reducing-the-frequency-of-major-gc-pauses.html

gc頻繁的暫停啟動

總結

以上是生活随笔為你收集整理的gc频繁的暂停启动_减少主要GC暂停的频率的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。