從不同角度分析垃圾收集器，可以將其劃分為不同的模型。

按線程數分，可以分為串行垃圾回收器和并行垃圾回收器；按照工作模式分，可以分為并發式垃圾回收器和獨占式垃圾回收器；按碎片處理方式可分為壓縮式垃圾回收器和非壓縮式垃圾回收器；而按工作的內存區間，又可分為新生代垃圾回收器和老年代垃圾回收器。本文就基于工作的內存區間劃分，來介紹七種經典的垃圾回收器，下圖是它們的工作區間以及搭配方式。

Young generation

Serial 收集器

看名字就能猜到，這個收集器是一個單線程工作的收集器，但是它的“單線程”的意義并不僅僅是說明它只會使用一個處理器或一條收集線程去完成垃圾收集工作，更重要的是強調在它進行垃圾收集時，必須暫停其他所有工作線程，直到它工作結束。同時，其采用的是標記復制算法。

Serial 是 JDK 1.3.1 之前新生代的唯一選擇，雖然看起來這個垃圾收集器好像老而無用了。但是事實上它依然是 HotSpot 虛擬機運行在客戶端模式下的默認新生代垃圾收集器，有著優于其他收集器的地方，那就是簡單而高效（與其他收集器的單線程相比），對于內存資源受限的環境，它是所有收集器里額外內存消耗（Memory Footprint）最小的；

ParNew 收集器

ParNew 收集器實際上是 Serial 收集器的多線程并行版本，除了同時使用多條線程進行垃圾收集之外，其余的行為包括 Serial 收集器可用的所有控制參數、收集算法、Stop The World、對象分配規則、回收策略等都與 Serial 收集器完全一一致。

ParNew 收集器除了支持多線程并行收集外，其他與 Serial 收集器相比并沒有太多的創新之處，但它卻是不少運行在服務端模式下的 HotSpot 虛擬機，尤其是 JDK 7 之前的遺留系統首選的新生代收集器，其中有一個與功能、性能無關但其實很重要的原因：除了 Serial 收集器外，目前只有它能與 CMS 收集器配合工作。

ParNew 收集器在單核心處理器的環境中絕對不會有比 Serial 收集器更好的效果。它默認開啟的收集線程與處理核心數量相同，在處理器核心非常多的環境下，可以使用 -XX:ParallelGCThreads 來限制垃圾回收器的線程數。

Parallel Scavenge 收集器

Parallel Scavenge 收集器也是一款新生代收集器，同樣是基于標記-復制算法實現的收集器，其從表面上看與 ParNew 十分相似，但它的關注點與其他收集器不同，CMS 等收集器的關注點是盡可能地縮短垃圾收集時用戶線程的停頓時間，而 Parallel Scavenge 收集器的目標則是達到一個可控制的吞吐量（Throughput）。

所謂吞吐量就是處理器用于運行用戶代碼的時間與處理器總消耗的時間的比值，即：

[吞吐量 = frac{運行用戶代碼時間}{運行用戶代碼時間 + 運行垃圾收集時間}
]

Tenured generation

Serial Old 收集器

Serial Old 是 Serial 收集器的老年代版本，同樣也是一個單線程工作的收集器，使用標記整理算法。

這個收集器的主要意義也是提供客戶端模式下的 HotSpot 虛擬機使用。如果在服務端模式下，它也可能有兩種用途：一種是在 JDK 5 以前的版本中與 Parallel Scavenge 收集器搭配使用，另外一種就是做為 CMS 收集器發生失敗時的后備預案，在并發收集發生 Concurrent Mode Failure 時使用。

Parallel Old 收集器

Parallel Old 是 Parallel Scavenge 收集器的老年代版本，支持多線程并發收集，基于標記整理算法。

其主要與 Parallel Scavenge 做搭配。

CMS 收集器

CMS（Concurrent Mark Sweep）收集器是一種以獲取最短回收停頓時間為目標的收集器。從名字上就可以看出 CMS 收集器是基于標記-清除算法實現的，它的運作過程相對于前面幾種收集器來說要更復雜一些，整個過程分為四個步驟，包括：

初始標記（CMS initial mark）
并發標記（CMS concurrent mark）
重新標記（CMS remark）
并發標記（CMS concurrent sweep）

其中并發標記以及重新標記這兩個步驟仍然需要“Stop The World”。

初始標記僅僅只是標記一下GC Roots能直接關聯到的對象，速度很快；

并發標記就是從GC Roots的直接關聯對象開始遍歷整個對象圖的過程，這個過程耗時很長但是不需要停頓用戶線程，可以與垃圾收集線程一起并發運行；

而重新標記階段則是為了修正并發標記期間，因用戶程序繼續運作而導致標記產生變動的那一部分對象的標記記錄，這個階段的停頓時間通常會比初始標記階段稍微長一些，但也遠比并發標記階段的時間短；

最后是并發清除階段，清除刪除掉標記階段判斷的已經死亡的對象，由于不需要移動存活對象，所以這個階段也是可以與用戶線程并發進行的。

CMS 的優點很明顯：并發收集、低停頓。但它也有很明顯的缺點：

CMS收集器對處理器資源非常敏感。事實上，面向并發設計的程序都對處理器資源比較敏感。在并發階段，它雖然不會導致用戶線程停頓，但卻會因為占用了一部分線程（或者說處理器的計算能力）而導致應用線程變慢，降低總吞吐量。

由于CMS收集器無法處理“浮動垃圾”（Floating Garbage），有可能出現”Concurrent Mode Failure“失敗進而導致另一次完全”Stop The World“的 Full GC 的產生。

浮動垃圾：并發清理階段用戶線程還在運行，這段時間內就可能產生新的垃圾，新的垃圾在此次 GC 無法清除，只能等到下次清理。這些垃圾有個專業的名詞：浮動垃圾；

CMS 是一款基于”標記-清除“的算法實現的垃圾收集器，這意味著收集結束時會有大量的空間碎片產生。空間碎片過多時，將會給大對象的分配帶來很大的麻煩，往往會出現老年代還有很多剩余空間，但就是無法找到足夠大的連續空間來分配當前對象。

Garbage First

為解決CMS算法產生空間碎片和其它一系列的問題缺陷，HotSpot提供了另外一種垃圾回收策略，G1（Garbage First）算法，通過參數-XX:+UseG1GC來啟用，該算法在JDK 7u4版本被正式推出，官網對此描述如下：

The Garbage-First (G1) collector is a server-style garbage collector, targeted for multi-processor machines with large memories. It meets garbage collection (GC) pause time goals with a high probability, while achieving high throughput. The G1 garbage collector is fully supported in Oracle JDK 7 update 4 and later releases. The G1 collector is designed for applications that:

Can operate concurrently with applications threads like the CMS collector.

Compact free space without lengthy GC induced pause times.

Need more predictable GC pause durations.

Do not want to sacrifice a lot of throughput performance.

Do not require a much larger Java heap.

在 G1 算法中，采用了另外一種完全不同以往的組織堆內存，堆內存被劃分為多個大小相等的內存塊（Region），每個Region是邏輯連續的一段內存，結構如下：

每個Region被標記了E、S、O和H，說明每個Region在運行時都充當了一種角色，其中H是以往算法中沒有的，它代表Humongous，這表示這些Region存儲的是巨型對象（humongous object，H-obj），當新建對象大小超過Region大小一半時，直接在新的一個或多個連續Region中分配，并標記為H。

G1 中提供了三種模式垃圾回收模式，young GC、mixed GC 和 full GC，在不同的條件下被觸發。

Young GC

發生在年輕代的GC算法，一般對象（除了巨型對象）都是在eden region中分配內存，當所有eden region被耗盡無法申請內存時，就會觸發一次 Young GC，這種觸發機制和之前的 young GC 差不多，執行完一次 Young GC，活躍對象會被拷貝到survivor region或者晉升到old region中，空閑的region會被放入空閑列表中，等待下次被使用。

Mixed GC

當越來越多的對象晉升到老年代old region時，為了避免堆內存被耗盡，虛擬機會觸發一個混合的垃圾收集器，即 mixed gc，該算法并不是一個 Old GC，除了回收整個 Young region，還會回收一部分的 Old Region，這里需要注意：是一部分老年代，而不是全部老年代，可以選擇哪些 Old region 進行收集，從而可以對垃圾回收的耗時時間進行控制。

mixed GC 的執行過程有點類似 CMS，主要分為以下幾個步驟：

initial mark: 初始標記過程，整個過程 STW，標記了從GC Root可達的對象
concurrent marking: 并發標記過程，整個過程 GC collector線程與應用線程可以并行執行，標記出GC Root可達對象衍生出去的存活對象，并收集各個Region的存活對象信息
remark: 最終標記過程，整個過程 STW，標記出那些在并發標記過程中遺漏的，或者內部引用發生變化的對象
clean up: 垃圾清除過程，如果發現一個Region中沒有存活對象，則把該 Region 加入到空閑列表中

Full GC

如果對象內存分配速度過快，Mixed GC 來不及回收，導致老年代被填滿，就會觸發一次 Full GC，G1 的 Full GC 算法就是單線程執行的 serial old gc，會導致異常長時間的暫停時間，需要進行不斷的調優，盡可能的避免 Full GC.

總結

以上是生活随笔為你收集整理的【JVM】Java 中的经典垃圾回收器的全部內容，希望文章能夠幫你解決所遇到的問題。

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