不同的Java垃圾回收器的比較

4款Java垃圾回收器——錯誤的選擇導致糟糕的性能

現在已經是2014年了，但是對大多數開發人員而言有兩件事情仍然是個謎——垃圾回收以及異性（碼農又被嘲笑了）。由于我對后者也不是特別了解，我 想我還是試著說說前者吧，尤其是隨著Java 8的到來，這個領域也發生了許多重大的變化及提升，其中最重要的莫過于持久代（PermGen）的刪除以及一些令人振奮的新的優化（后面會陸續提及這 些）。

說起垃圾回收，許多人都了解它的概念，也在日常的編程中有所應用。盡管如此，仍有許多我們不太了解的東西，而這正是痛苦的根源。關于JVM最大的誤 解就是認為它只有一個垃圾回收器，而事實上它有四個不同的回收器，每個都各有其長短。JVM并不會自動地選擇某一個，這事還得落在你我的肩上，因為不同的 回收器會帶來吞吐量及應用的暫停時間的顯著的差異。

這四種回收算法的共同之處在于它們都是分代的，也就是說它們將托管的堆分成了好幾個區域，它假設堆中的許多對象的生命周期都很短，可以很快被回收掉。介紹這塊內容的已經很多了，因此這里我打算直接講一下這幾個不同的算法，以及它們的長處及短處。

1.串行回收器

串行回收器是最簡單的一個，你都不會考慮使用它，因為它主要是面向單線程環境的（比如說32位的或者Windows）以及比較小的堆。這個回收器工作的時候會將所有應用線程全部凍結，就這一點而言就使得它完全不可能會被服務端應用所采用。

如何使用它：你可以打開-XX:+UseSerialGC這個JVM參數來使用它。

2.并行/吞吐量回收器

下一個是并行回收器（ Parallel collector）。這是JVM的默認回收器。正如它的名字所說的那樣，它的最大的優點就是它使用多個線程來掃描及壓縮堆。它的缺點就是不管執行的是 minor GC還是full GC它都會暫停應用線程。并行回收器最適合那些可以容許暫停的應用，它試圖減少由回收器所引起的CPU開銷。

3.CMS回收器

并行回收器之后就是CMS回收器了（concurrent-mark-sweep）。這個算法使用了多個線程（concurrent）來掃描堆并標 記（mark）那些不再使用的可以回收(sweep)的對象。這個算法在兩種情況下會進入一個”stop the world”的模式：當進行根對象的初始標記的時候 （老生代中線程入口點或靜態變量可達的那些對象）以及當這個算法在并發運行的時候應用程序改變了堆的狀態使得它不得不回去再次確認自己標記的對象都是正確 的。

使用這個回收器最大的問題就是會碰到promotion failure，這是指在回收新生代及年老代時出現了競爭條件的情況。如果回收器需要將年輕的對象提升到年老代中，而這個時候年老代沒有多余的空間了，它 就只能先進行一次STW(Stop The World)的full GC了——這種情況正是CMS所希望避免的。為了確保這種情況不會發生，你要么就是增加老生代的大小（或者增加整個堆的大小），要么就是給回收器分配一些 后臺線程以便與對象分配的速度進行賽跑。

這個算法的另一個缺點就是和并行回收器相比，它使用的CPU資源會更多，它使用了多個線程來執行掃描和回收，這樣才能讓應用持續提供更高級別的吞吐 量。對于大多數長期運行的程序而言，應用的暫停對它們是很不利的，這個時候可以考慮使用CMS回收器。盡管如此，這個算法也不是默認開啟的。你得指定 XX:+UseConcMarkSweepGC來啟用它。假設你的堆小于4G，而你又希望分配更多的CPU資源以避免應用暫停，那么這就是你要選擇的回收 器。然而，如果堆大于4G的話，你可能更希望使用最后的這個——G1回收器。

4.G1回收器

G1（ Garbage first）回收器在JDK 7update 4中首次引入，它的設計目標是能更好地支持大于4GB的堆。G1回收器將堆分為多個區域，大小從1MB到32MB不等，并使用多個后臺線程來掃描它們。 G1回收器會優先掃描那些包含垃圾最多的區域，這正是它的名字的由來（Garbage first）。這個回收器可以通過-XX:UseG1GC標記來啟用。

這一策略減少了后臺線程還未掃描完無用對象前堆就已經用光的可能性，而那種情況回收器就必須得暫停應用，這就會導致STW回收。G1的另一個好處就是它總是會進行堆的壓縮，而CMS回收器只有在full GC的時候才會干這事。

過去幾年里，大堆一直都是一個充滿爭議的領域，很多開發人員從單機器單JVM模型轉向了單機器多JVM的微服務，組件化的架構。這是許多因素所驅動的，包括隔離程序的組件，簡化部署，避免重新加載應用類到內存所產生的開銷（Java 8中這點已經得到了改善）。

盡管如此，這么做最主要還是希望能避免大堆的GC中長時期的”stop the world”的暫停（在一次大的回收中需要花費數秒才能完成）。像Docker這樣的容器技術也加速了這一進程，它們使得你可以很輕松地在同一臺物理機上部署多個應用。

Java 8及G1回收器

Java 8 update 20所引入的一個很棒的優化就是G1回收器中的字符串去重（String deduplication）。由于字符串(包括它們內部的char[]數組）占用了大多數的堆空間，這項新的優化旨在使得G1回收器能識別出堆中那些重 復出現的字符串并將它們指向同一個內部的char[]數組，以避免同一個字符串的多份拷貝，那樣堆的使用效率會變得很低。你可以使用 -XX:+UseStringDeduplication這個JVM參數來試一下這個特性。

Java 8及持久代

Java 8中最大的改變就是持久代的移除，它原本是用來給類元數據，駐留字符串，靜態變量來分配空間的。這在以前都是需要開發人員來針對那些會加載大量類的應用來 專門進行堆比例的優化及調整。許多年來都是如此，這也正是許多OutOfMemory異常的根源，因此由JVM來接管它真是再好不過了。即便如此，它本身 并不會減少開發人員將應用解耦到不同的JVM中的可能性。

每個回收器都有許多不同的開關和選項來進行調優，這可能會增加吞吐量，也可能會減少，這取決于你的應用的具體的行為了。在下一篇文章中我們會深入講解配置這些算法的關鍵策略。