垃圾收集算法,垃圾收集器

我們的研究實驗室正全速前進。 隨著最近的資本注入 ，我們只能保證我們不斷創新的步伐只會加快。 我們進行的部分研究與GC優化有關。 在處理這個有趣的領域中的問題時，我們認為可以分享一些有關GC算法使用的見解。

為此，我們對使用特定GC算法的頻率進行了研究。 結果有些令人驚訝。 讓我從數據的背景開始–我們可以訪問來自84,936個會話的數據，這些會話代表2670種不同的環境用于研究。 13％的環境明確指定了GC算法。 其余的決定權交給了JVM。 因此，在使用顯式GC算法的11,062會話中，我們能夠區分出六種不同的GC算法：

在了解有關GC算法用法的詳細信息之前，我們應該停一分鐘，然后嘗試理解為什么上面的餅圖中缺少87％的運行。 我們認為，這是兩個不同根本原因的征兆

• 首先也是有充分理由的是– JVM在選擇合理的默認值方面已經表現出色，以至于開發人員不再需要深入研究。 如果您的應用程序吞吐量和延遲足夠，那么–為什么要打擾？
• 缺少GC算法的第二個可能原因表明，應用程序性能并不是團隊的首要任務。 正如我們去年的案例研究所表明的那樣，僅需調整一項配置即可顯著提高吞吐量和延遲。

因此，我們有將近83,000個使用默認GC選擇運行的JVM。 但是默認值是什么？ 答案既簡單又復雜。 如果認為您正在客戶端JVM上運行，則JVM所應用的默認值為串行GC（-XX：+ UseSerialGC）。 在服務器級計算機上，默認值為并行GC（-XX：+ UseParallelGC）。 可以基于以下決策表確定是在服務器還是客戶端類計算機上運行：

建筑	CPU /內存	操作系統	默認
i586	任何	微軟視窗	客戶
AMD64	任何	任何	服務器
64位SPARC	任何	的Solaris	服務器
32位SPARC	2個以上內核和> 2GB RAM	的Solaris	服務器
32位SPARC	1核或<2GB RAM	的Solaris	客戶
i568	2個以上內核和> 2GB RAM	Linux或Solaris	服務器
i568	1核或<2GB RAM	Linux或Solaris	客戶

但是，讓我們回到在配置中已明確指定GC算法的13％的人。 它以良好的舊串行模式開始，毫無疑問，它的用戶群如此之小，以至于在上圖中幾乎看不到它。 實際上，只有31個環境確定這是最佳的GC算法，并且已明確指定了該算法。 考慮到當今大多數平臺都在多核計算機上運行，??您應該不會感到驚訝–當您擁有多個核時，幾乎總是建議從串行模式切換。

GC	計數
序列號	31
平行	1,422
平行舊	1,193
ConcMarkSweep	6,655
CMSIncrementalMode	935
G1	826

其余配置可以分為三組-并行，并發和G1。 贏家是顯而易見的-并發標記和掃描算法相結合構成了樣本的三分之二以上。 但是，讓我們更深入地研究結果。

Parallel和ParallelOld模式大致在同一鄰域中，具有1,422和1,193個樣本。 不足為奇–如果您確定并行模式適合您的年輕一代，那么對于老一代而言，相同的算法通常也表現良好。 并行模式中另一個有趣的方面是–從上面可以看出，并行模式是大多數常見平臺上的默認模式，因此缺乏明確的規范并不意味著它不比其他模式流行。

對于CMS，我們的期望有所不同。 即–與具有6556種配置的傳統CMS相比，增量模式僅在935次打開。 提醒您-在并發階段，垃圾收集器線程正在使用一個或多個處理器。 增量模式用于通過定期停止并發階段以使處理器退還給應用程序來減少長時間的并發階段的影響。 這樣可以縮短暫停時間，尤其是在處理器數量少的機器上。 目前尚不清楚環境是全部擁有海量核心，還是負責配置的人員都不知道增量模式的好處。

但是我們最大的驚喜與G1的采用率有關。 G1作為垃圾收集算法正在運行826個環境。 根據我們的經驗，無論您是追求吞吐量還是等待時間，G1的表現都比CMS差。 也許我們可以訪問的測試用例的選擇不多，但是目前我們認為G1需要更多的時間來實際兌現其承諾。 因此，如果您是快樂的G1用戶，也許可以與我們分享您的經驗？

參考： 您正在使用什么垃圾收集器？ 由我們的JCG合作伙伴 Nikita Salnikov Tarnovski在Plumbr Blog博客上獲得。

翻譯自: https://www.javacodegeeks.com/2013/11/what-garbage-collector-are-you-using.html

垃圾收集算法,垃圾收集器

總結

以上是生活随笔為你收集整理的垃圾收集算法,垃圾收集器_您正在使用什么垃圾收集器？的全部內容，希望文章能夠幫你解決所遇到的問題。

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