JVM-垃圾回收器

時間 2019-12-13

標籤 jvm 垃圾回收欄目 Java 简体版

原文原文鏈接

目錄java

垃圾收集器

垃圾收集器

Serial收集器
ParNew收集器
Parallel Scavenge收集器
CMS收集器
G1收集器

若是說收集算法是內存回收的方法論，那麼垃圾收集器就是內存回收的具體實現。算法

雖然咱們對各個收集器進行比較，但並不是要挑選出一個最好的收集器。由於知道如今爲止尚未最好的垃圾收集器出現，更加沒有萬能的垃圾收集器，咱們能作的就是根據具體應用場景選擇適合本身的垃圾收集器。試想一下：若是有一種四海以內、任何場景下都適用的完美收集器存在，那麼咱們的 HotSpot 虛擬機就不會實現那麼多不一樣的垃圾收集器了。服務器

Serial收集器

Serial（串行）收集器收集器是最基本、歷史最悠久的垃圾收集器了。你們看名字就知道這個收集器是一個單線程收集器了。它的「單線程」的意義不只僅意味着它只會使用一條垃圾收集線程去完成垃圾收集工做，更重要的是它在進行垃圾收集工做的時候必須暫停其餘全部的工做線程（ "Stop The World" ），直到它收集結束。多線程

新生代採用複製算法,老年代採用標記-整理算法閉包

可是 Serial 收集器有沒有優於其餘垃圾收集器的地方呢？固然有，它簡單而高效（與其餘收集器的單線程相比）。Serial 收集器因爲沒有線程交互的開銷，天然能夠得到很高的單線程收集效率。Serial 收集器對於運行在 Client 模式下的虛擬機來講是個不錯的選擇。併發

Serial Old 收集器

Serial 收集器的老年代版本，它一樣是一個單線程收集器。它主要有兩大用途：一種用途是在 JDK1.5 以及之前的版本中與 Parallel Scavenge 收集器搭配使用，另外一種用途是做爲 CMS 收集器的後備方案。性能

ParNew 收集器

ParNew 收集器其實就是 Serial 收集器的多線程版本，除了使用多線程進行垃圾收集外，其他行爲（控制參數、收集算法、回收策略等等）和 Serial 收集器徹底同樣。優化

新生代採用複製算法,老年代採用標記-整理算法線程

它是許多運行在 Server 模式下的虛擬機的首要選擇，除了 Serial 收集器外，只有它能與 CMS 收集器（真正意義上的併發收集器）配合工做。對象

Parallel Scavenge 收集器 (並行清除) /'pærəlɛl/ /'skævɪndʒ/

Parallel Scavenge 收集器相似於 ParNew 收集器.

Parallel Scavenge 收集器關注點是吞吐量（高效率的利用 CPU）。CMS 等垃圾收集器的關注點更多的是用戶線程的停頓時間（提升用戶體驗）。所謂吞吐量就是 CPU 中用於運行用戶代碼的時間與 CPU 總消耗時間的比值.

Parallel Scavenge 收集器提供了不少參數供用戶找到最合適的停頓時間或最大吞吐量，若是對於收集器運做不太瞭解的話，手工優化存在的話能夠選擇把內存管理優化交給虛擬機去完成也是一個不錯的選擇。

新生代採用複製算法,老年代採用標記-整理算法

Parallel Old 收集器

Parallel Scavenge 收集器的老年代版本。使用多線程和「標記-整理」算法。在注重吞吐量以及 CPU 資源的場合，均可以優先考慮 Parallel Scavenge 收集器和 Parallel Old 收集器。

CMS 收集器

CMS（Concurrent Mark Sweep）收集器是一種以獲取最短回收停頓時間爲目標的收集器。它很是符合在注重用戶體驗的應用上使用。

CMS（Concurrent Mark Sweep）收集器是 HotSpot 虛擬機第一款真正意義上的併發收集器，它第一次實現了讓垃圾收集線程與用戶線程（基本上）同時工做。

從名字中的Mark Sweep這兩個詞能夠看出，CMS 收集器是一種 標記-清除算法實現的，它的運做過程相比於前面幾種垃圾收集器來講更加複雜一些。整個過程分爲四個步驟：

初始標記：暫停全部的其餘線程，並記錄下直接與GC root相連的對象，速度很快；
併發標記：同時開啓GC和用戶線程，用一個閉包結構去記錄可達對象。但在這個階段結束，這個閉包結構並不能保證包含當前全部的可達對象。由於用戶線程可能會不斷的更新引用域，因此GC線程沒法保證可達性分析的實時性。因此這個算法裏會跟蹤記錄這些發生引用更新的地方。
從新標記：從新標記階段就是爲了修正併發標記期間由於用戶程序繼續運行而致使標記產生變更的那一部分對象的標記記錄，這個階段的停頓時間通常會比初始標記階段的時間稍長，遠遠比並發標記階段時間短
併發清除：開啓用戶線程，同時 GC 線程開始對爲標記的區域作清掃。

注意初始標記和從新標記仍是會stop the world，可是在耗費時間更長的併發標記和併發清除兩個階段均可以和用戶進程同時工做。

從它的名字就能夠看出它是一款優秀的垃圾收集器，主要優勢：併發收集、低停頓。可是它有下面三個明顯的缺點：

對 CPU 資源敏感；
沒法處理浮動垃圾；
它使用的回收算法-「標記-清除」算法會致使收集結束時會有大量空間碎片產生。

G1 收集器

G1 (Garbage-First) 是一款面向服務器的垃圾收集器,主要針對配備多顆處理器及大容量內存的機器. 以極高機率知足 GC 停頓時間要求的同時,還具有高吞吐量性能特徵.

G1 GC 這是一種兼顧吞吐量和停頓時間的 GC 實現，是 JDK 9 之後的默認 GC 選項。G1 能夠直觀的設定停頓時間的目標，相比於 CMS GC，G1 未必能作到 CMS 在最好狀況下的延時停頓，可是最差狀況要好不少。

被視爲 JDK1.7 中 HotSpot 虛擬機的一個重要進化特徵。它具有一下特色：

並行與併發：G1 能充分利用 CPU、多核環境下的硬件優點，使用多個 CPU（CPU 或者 CPU 核心）來縮短 Stop-The-World 停頓時間。部分其餘收集器本來須要停頓 Java 線程執行的 GC 動做，G1 收集器仍然能夠經過併發的方式讓 java 程序繼續執行。
分代收集：雖然 G1 能夠不須要其餘收集器配合就能獨立管理整個 GC 堆，可是仍是保留了分代的概念。
空間整合：與 CMS 的「標記--清理」算法不一樣，G1 從總體來看是基於「標記整理」算法實現的收集器；從局部上來看是基於「複製」算法實現的。
可預測的停頓：這是 G1 相對於 CMS 的另外一個大優點，下降停頓時間是 G1 和 CMS 共同的關注點，但 G1 除了追求低停頓外，還能創建可預測的停頓時間模型，能讓使用者明確指定在一個長度爲 M 毫秒的時間片斷內。

G1 收集器的運做大體分爲如下幾個步驟：

初始標記:標記 GC Roots 直接關聯的對象，須要 Stop The World 。
併發標記:從 GC Roots 開始對堆進行可達性分析，找出活對象。
最終標記:從新標記階段爲了修正併發期間因爲用戶進行運做致使的標記變更的那一部分對象的標記記錄。這個階段的停頓時間通常會比初始標記階段稍長一些，但遠比並發標記的時間短，也須要 Stop The World 。
篩選回收:首先對各個 Region 的回收價值和成本進行排序，根據用戶所指望的 GC 停頓時間來制定回收計劃。這個階段能夠與用戶程序一塊兒併發執行，可是由於只回收一部分 Region，時間是用戶可控制的。

G1 收集器在後臺維護了一個優先列表，每次根據容許的收集時間，優先選擇回收價值最大的 Region(這也就是它的名字 Garbage-First 的由來)。這種使用 Region 劃份內存空間以及有優先級的區域回收方式，保證了 G1 收集器在有限時間內能夠儘量高的收集效率（把內存化整爲零）。

雖然G1看起來有不少優勢，實際上CMS仍是主流。

幾種收集器對比

Serial收集器 VS ParNew收集器

ParNew收集器在單CPU的環境中絕對不會有比Serial收集器更好的效果，甚至因爲存在線程交互的開銷，該收集器在經過超線程技術實現的兩個CPU的環境中都不能百分之百地保證能夠超越Serial收集器。
然而，隨着可使用的CPU的數量的增長，它對於GC時系統資源的有效利用仍是頗有好處的。

Parallel Scavenge收集器 VS CMS等收集器

Parallel Scavenge收集器的特色是它的關注點與其餘收集器不一樣，CMS等收集器的關注點是儘量地縮短垃圾收集時用戶線程的停頓時間，而Parallel Scavenge收集器的目標則是達到一個可控制的吞吐量（Throughput）。
因爲與吞吐量關係密切，Parallel Scavenge收集器也常常稱爲「吞吐量優先」收集器。

Parallel Scavenge收集器 VS ParNew收集器

Parallel Scavenge收集器與ParNew收集器的一個重要區別是它具備自適應調節策略。

GC自適應的調節策略（GC Ergonomics）:

Parallel Scavenge收集器有一個參數-XX:+UseAdaptiveSizePolicy。當這個參數打開以後，就不須要手工指定新生代的大小、Eden與Survivor區的比例、晉升老年代對象年齡等細節參數了，虛擬機會根據當前系統的運行狀況收集性能監控信息，動態調整這些參數以提供最合適的停頓時間或者最大的吞吐量，這種調節方式稱爲GC自適應的調節策略（GC Ergonomics）。