七款經典垃圾回收器

Serial

Serial 是一款單線程的垃圾回收器，在進行垃圾回收的時候會發生Stop the world 。
對於其餘垃圾收集器而言，他的內存佔用是最小的。

ParNew

ParNew 其實是Serial 收集器的並行版本

Parallel Scavenge

注重吞吐量的垃圾收集器。
吞吐量= 運行用戶代碼的時間/(垃圾回收的時間+運行用戶代碼的時間)
他有兩個參數用於精確控制吞吐量大小：
-XX:MaxGCPauseMills:控制垃圾回收的時間
這個值並非越小越好，咱們知道，內存越小，進行垃圾回收的時間就越短。若是咱們將這個值設置地較小，那麼回收的內存部分也就小。這也就致使gc 進行垃圾回收的頻率也越高，這樣吞吐量也就降低了。
-XX:GCTimeRatio:垃圾回收時間的比例
這個值默認是99 .也就是說 垃圾回收的時間只佔1%（1/1+99）

Serial Old

是serial收集器的老年代版本
有兩個用途

• 在jdk5及以前的版本中與Parallel Scavenge 收集器搭配使用
• 在cms收集器發生失敗的後備預案

Parallel Old

是Parallel Scavenge 的老年代版本

CMS(Current Mark and Sweep)

真正意義上的併發收集器，第一次實現了讓垃圾收集線程與用戶線程(基本上)同時工做
整個過程能夠分爲四部分：

• 初始標記
  掃描和GCRoots直接關聯的對象，速度很快
• 併發標記
  遍歷整個對象圖，時間較長
• 從新標記
  標記產生變更的那一部分對象的標記記錄
• 併發清楚
  清標記階段斷定死亡的對象

缺點：
資源敏感：
CMS的默認啓動的垃圾回收線程是（處理器核心數+3）/4，那麼在覈心數>4 的時候，回收線程只佔用不超過25%的處理器運算資源，而且會隨着核心數的增長而降低。當核心數<4，CMS對用戶線程的影響就變得很大。
併發問題：
用戶線程和gc線程同時進行時，會產生一些"浮動垃圾"，可是CMS沒法處理"浮動垃圾",有可能出現 Concurrent Mode Failure 失敗，進而致使另外一次徹底的STW 的full GC 出現。
CMS沒法在此次垃圾收集中進行回收，只能等待下一次垃圾回收的時候回收。

內存佈局問題：
由於CMS是標記並清除算法實現的，也就是說，在進行垃圾回收後的內存佈局是零散的，不是連續的。所以，可能存在爲大對象分配空間時候出現內存不足的狀況，從而致使JVM發生full GC ，產生STW，這是難以讓人接受的。
解決方法：

• 一種是在進行必定次數後，進行一次內存整理。（-XX:CMSFullGCsBeforeCompaction）
• 另外一種是在須要發生full GC 以前進行一次內存整理。(-XX:+UseCMSCompactionAtFullCollection)

Garbage First

停頓時間模型--在一個長度爲M毫秒的時間內，進行垃圾回收的時間大機率不超過N毫秒。
面向局部收集的思路和基於region的內存佈局形式

G1把內存劃分爲多個大小相等的獨立和空間，每個region根據須要扮演不一樣的角色。當須要分配大對象的時候，會將連續的Region分區劃給這個大對象（Humougous）。
回收策略：
G1收集器去跟蹤各個region中的垃圾的價值（回收所得到的空間大小以及回收須要時間的經驗值），而後在後臺維護一個優先級列表，每次根據設定的停頓時間來優先回收知足條件的region。
回收過程：

• 初始標記
• 併發標記
• 最終標記
• 篩選回收