說明：垃圾回收演算法是理論，垃圾收集器是回收演算法的實現，關於回收演算法，見《第四章 JVM垃圾回收演算法》

1、七種垃圾收集器

• Serial（序列GC）-- 複製
• ParNew（並行GC）-- 複製
• Parallel Scavenge（並行回收GC）-- 複製
• Serial Old（MSC）（序列GC）-- 標記-整理
• CMS（併發GC）-- 標記-清除
• Parallel Old（並行GC）--標記-整理
• G1（JDK1.7update14才可以正式商用）

說明：

• 1~3用於年輕代垃圾回收：年輕代的垃圾回收稱為minor GC
• 4~6用於年老代垃圾回收（當然也可以用於方法區的回收
  ）：年老代的垃圾回收稱為full GC
• G1獨立完成"分代垃圾回收"

注意：並行與併發

• 並行：多條垃圾回收執行緒同時操作
• 併發：垃圾回收執行緒與使用者執行緒一起操作

2、常用五種組合

• Serial/Serial Old
• ParNew/Serial Old：與上邊相比，只是比年輕代多了多執行緒垃圾回收而已
• ParNew/CMS：當下比較高效的組合
• Parallel Scavenge/Parallel Old：自動管理的組合
• G1：最先進的收集器，但是需要JDK1.7update14以上

2.1、Serial/Serial Old：

特點：

• 年輕代Serial收集器採用單個GC執行緒實現"複製"演算法（包括掃描、複製）
• 年老代Serial Old收集器採用單個GC執行緒實現"標記-整理"演算法
• Serial與Serial Old都會暫停所有使用者執行緒（即STW）

說明：

• STW（stop the world）：編譯程式碼時為每一個方法注入safepoint（方法中迴圈結束的點、方法執行結束的點），在暫停應用時，需要等待所有的使用者執行緒進入safepoint，之後暫停所有執行緒，然後進行垃圾回收。

適用場合：

• CPU核數<2，實體記憶體<2G的機器（簡單來講，單CPU，新生代空間較小且對STW時間要求不高的情況下使用）
• -XX:UseSerialGC：強制使用該GC組合
• -XX:PrintGCApplicationStoppedTime：檢視STW時間

2.2、ParNew/Serial Old：

說明：

• ParNew除了採用多GC執行緒來實現複製演算法以外，其他都與Serial一樣，但是此組合中的Serial Old又是一個單GC執行緒，所以該組合是一個比較尷尬的組合，在單CPU情況下沒有Serial/Serial Old速度快（因為ParNew多執行緒需要切換），在多CPU情況下又沒有之後的三種組合快（因為Serial Old是單GC執行緒），所以使用其實不多。
• -XX:ParallelGCThreads：指定ParNew GC執行緒的數量，預設與CPU核數相同，該引數在於CMS GC組合時，也可能會用到

2.3、Parallel Scavenge/Parallel Old：

特點：

• 年輕代Parallel Scavenge收集器採用多個GC執行緒實現"複製"演算法（包括掃描、複製）
• 年老代Parallel Old收集器採用多個GC執行緒實現"標記-整理"演算法
• Parallel Scavenge與Parallel Old都會暫停所有使用者執行緒（即STW）

說明：

•  吞吐量：CPU執行程式碼時間/(CPU執行程式碼時間+GC時間)
• CMS主要注重STW的縮短（該時間越短，使用者體驗越好，所以主要用於處理很多的互動任務的情況）
• Parallel Scavenge/Parallel Old主要注重吞吐量（吞吐量越大，說明CPU利用率越高，所以主要用於處理很多的CPU計算任務而使用者互動任務較少的情況）

引數設定：

• -XX:+UseParallelOldGC：使用該GC組合
• -XX:GCTimeRatio：直接設定吞吐量大小，假設設為19，則允許的最大GC時間佔總時間的1/(1+19)，預設值為99，即1/(1+99)
• -XX:MaxGCPauseMillis：最大GC停頓時間，該引數並非越小越好
• -XX:+UseAdaptiveSizePolicy：開啟該引數，-Xmn/-XX:SurvivorRatio/-XX:PretenureSizeThreshold這些引數就不起作用了，虛擬機器會自動收集監控資訊，動態調整這些引數以提供最合適的的停頓時間或者最大的吞吐量（GC自適應調節策略），而我們需要設定的就是-Xmx，-XX:+UseParallelOldGC或-XX:GCTimeRatio兩個引數就好（當然-Xms也指定上與-Xmx相同就好）

注意：

• -XX:GCTimeRatio和-XX:MaxGCPauseMillis設定一個就好
• 不開啟-XX:+UseAdaptiveSizePolicy，-Xmn/-XX:SurvivorRatio/-XX:PretenureSizeThreshold這些引數依舊可以配置，以resin伺服器為例

              <jvm-arg>-Xms2048m</jvm-arg>
              <jvm-arg>-Xmx2048m</jvm-arg>
              <jvm-arg>-Xmn512m</jvm-arg>
              <jvm-arg>-Xss1m</jvm-arg>
              <jvm-arg>-XX:PermSize=256M</jvm-arg>
              <jvm-arg>-XX:MaxPermSize=256M</jvm-arg>
              <jvm-arg>-XX:SurvivorRatio=8</jvm-arg>
              <jvm-arg>-XX:MaxTenuringThreshold=15</jvm-arg>
  
              <jvm-arg>-XX:+UseParallelOldGC</jvm-arg>
              <jvm-arg>-XX:GCTimeRatio=19</jvm-arg>
  
              <jvm-arg>-XX:+PrintGCDetails</jvm-arg>
              <jvm-arg>-XX:+PrintGCTimeStamps</jvm-arg>

  View Code

適用場合：

• 很多的CPU計算任務而使用者互動任務較少的情況
• 不想自己去過多的關注GC引數，想讓虛擬機器自己進行調優工作

2.4、ParNew/CMS

說明：

• 以上只是年老代CMS收集的過程，年輕代ParNew看"2.2、ParNew/Serial Old"就好
• CMS是多回收執行緒的，不要被上圖誤導，預設的執行緒數：(CPU數量+3)/4
• CMS主要注重STW的縮短（該時間越短，使用者體驗越好，所以主要用於處理很多的互動任務的情況）

特點：

• 年輕代ParNew收集器採用多個GC執行緒實現"複製"演算法（包括掃描、複製）
• 年老代CMS收集器採用多執行緒實現"標記-清除"演算法
  • 初始標記：標記與根集合節點直接關聯的節點。時間非常短，需要STW
  • 併發標記：遍歷之前標記到的關聯節點，繼續向下標記所有存活節點。時間較長。
  • 重新標記：重新遍歷trace併發期間修改過的引用關係物件。時間介於初始標記與併發標記之間，通常不會很長。需要STW
  • 併發清理：直接清除非存活物件，清理之後，將該執行緒佔用的CPU切換給使用者執行緒
• 初始標記與重新標記都會暫停所有使用者執行緒（即STW），但是時間較短；併發標記與併發清理時間較長，但是不需要STW

關於併發標記期間怎樣記錄發生變動的引用關係物件，在重新標記期間怎樣掃描這些物件，見《第六章 JVM垃圾收集器（2）》

缺點：

• 併發標記與併發清理：按照說明的第二點來講，假設有2個CPU，那麼其中有一個CPU會用於垃圾回收，而另一個用於使用者執行緒，這樣的話，之前是兩CPU執行使用者執行緒，現在是一個，那麼效率就會急劇下降。也就是說，降低了吞吐量（即降低了CPU使用率）。
• 併發清理：在這一過程中，產生的垃圾無法被清理（因為發生在重新標記之後）
• 併發標記與併發清理：由於是與使用者執行緒併發的，所以使用者執行緒可能會分配物件，這樣既可能物件直接進入年老代（例如，大物件），也可能進入年輕代後，年輕代發生minor GC，這樣的話，實際上要求我們的年老代需要預留一定空間，也就是說要在年老代還有一定空間的情況下就要進行垃圾回收，留出一定記憶體空間來供其他執行緒使用，而不能等到年老代快爆滿了才進行垃圾回收，通過-XX:CMSInitiatingOccupancyFraction來指定當年老代空間滿了多少後進行垃圾回收，如果在回收過程中，老年代已經不夠使用了，這時候CMS回收失敗，老年代使用serial Old進行GC
• 標記-清理演算法：會產生記憶體碎片，由於是在老年代，可能會提前觸發Full GC（這正是我們要儘量減少的）

引數設定：

• -XX:+UseConcMarkSweepGC：使用該GC組合
• -XX:CMSInitiatingOccupancyFraction：指定當年老代空間滿了多少後進行垃圾回收
• -XX:+UseCMSCompactAtFullCollection：（預設是開啟的）在CMS收集器頂不住要進行FullGC時開啟記憶體碎片整理過程，該過程需要STW
• -XX:CMSFullGCsBeforeCompaction：指定多少次FullGC後才進行整理
• -XX:ParallelCMSThreads：指定CMS回收執行緒的數量，預設為：(CPU數量+3)/4

適用場合：

• 用於處理很多的互動任務的情況
• 方法區的回收一般使用CMS，配置兩個引數：-XX:+CMSPermGenSweepingEnabled與-XX:+CMSClassUnloadingEnabled

3、一些經驗

• 由於當下大型企業用的比較多的還是jdk1.6版本，所以G1用的還是不多
• 用得最多的兩種：ParNew/CMS和Parallel Scavenge/Parallel Old
• Full GC的四種情況
  • 舊生代空間不足
    • 不要建立過大的物件獲陣列
    • 儘量讓物件在minor GC被回收
    • 讓物件在年輕代多存活一段時間，可能這段時間內就會被minor GC回收
  • 方法區滿了
    • 增大方法區
    • 使用CMS GC回收方法區
  • CMS GC中promotion failed（minor GC時，survivor區放不下，年老區也放不下）和concurrent mode failure
    • 增大survivor區
    • 增大年老區
    • 調低-XX:CMSInitiatingOccupancyFraction
    • 設定：-XX:CMSMaxAbortablePrecleanTime=5(單位:ms)，防止CMS在重新標記很久後才進行併發清理
  • 空間擔保機制（這一塊兒見《深入理解Java虛擬機器（第二版）》P98）

附：具體的配置引數檢視《深入理解Java虛擬機器（第二版）》P90