JVM_12 垃圾回收3-垃圾回收器

時間 2020-07-06

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

原文原文鏈接

完整JVM學習筆記請戳

GC的分類與性能指標

垃圾收集器沒有在規範中進行過多的規定，能夠由不一樣的廠商、不一樣版本的JVM來實現。
因爲JDK的版本處於高速迭代過程當中，所以Java發展至今已經衍生了衆多的GC版本。
從不一樣角度分析垃圾收集器，能夠將GC分爲不一樣的類型。

按線程數分，能夠分爲串行垃圾回收器和並行垃圾回收器html

串行回收指的是在同一時間段內只容許有一個CPU用於執行垃圾回收操做，此時工做線程被暫停，直至垃圾收集工做結束。
- ➢在諸如單CPU處理器或者較小的應用內存等硬件平臺不是特別優越的場合，串行回收器的性能表現能夠超過並行回收器和併發回收器。因此，串行回收默認被應用在客戶端的Client模式下的JVM中
- ➢在併發能力比較強的CPU上，並行回收器產生的停頓時間要短於串行回收器。
和串行回收相反，並行收集能夠運用多個CPU同時執行垃圾回收，所以提高了應用的吞吐量，不過並行回收仍然與串行回收同樣，採用獨佔式，使用了「 Stop一the一world」機制。

按照工做模式分，能夠分爲併發式垃圾回收器和獨佔式垃圾回收器java

併發式垃圾回收器與應用程序線程交替工做，以儘量減小應用程序的停頓時間。
獨佔式垃圾回收器（Stop the world）一旦運行，就中止應用程序中的全部用戶線程，直到垃圾回收過程徹底結束。

按碎片處理方式分，可分爲壓縮式垃圾回收器和非壓縮式垃圾回收器git

壓縮式垃圾回收器會在回收完成後，對存活對象進行壓縮整理，消除回收後的碎片。
- 再分配對象空間使用: 指針碰撞
非壓縮式的垃圾回收器不進行這步操做。
- 再分配對象空間使用: 空閒列表

按工做的內存區間分，又可分爲年輕代垃圾回收器和老年代垃圾回收器github

評估GC的性能指標

==吞吐量：運行用戶代碼的時間佔總運行時間的比例==web
- （總運行時間：程序的運行時間十內存回收的時間）
垃圾收集開銷：吞吐量的補數，垃圾收集所用時間與總運行時間的比例。面試
==暫停時間：執行垃圾收集時，程序的工做線程被暫停的時間==算法
收集頻率：相對於應用程序的執行，收集操做發生的頻率。windows
==內存佔用： Java堆區所佔的內存大小==bash
快速：一個對象從誕生到被回收所經歷的時間。服務器
這三者共同構成一個「不可能三角」。三者整體的表現會隨着技術進步而愈來愈好。一款優秀的收集器一般最多同時知足其中的兩項。
這三項裏，暫停時間的重要性日益凸顯。由於隨着硬件發展，內存佔用多些愈來愈能容忍，硬件性能的提高也有助於下降收集器運行時對應用程序的影響，即提升了吞吐量。而內存的擴大，對延遲反而帶來負面效果。
簡單來講，主要抓住兩點：
- 吞吐量
- 暫停時間

吞吐量

吞吐量就是CPU用於運行用戶代碼的時間與CPU總消耗時間的比值，即吞吐量=運行用戶代碼時間/ （運行用戶代碼時間+垃圾收集時間）
- ➢好比：虛擬機總共運行了100分鐘，其中垃圾收集花掉1分鐘，那吞吐量就是99%
這種狀況下，應用程序能容忍較高的暫停時間，所以，高吞吐量的應用程序有更長的時間基準，快速響應是沒必要考慮的。
吞吐量優先，意味着在單位時間內，STW的時間最短： 0.2 + 0.2 = 0.4

暫停時間

「暫停時間」是指一個時間段內應用程序線程暫停，讓GC線程執行的狀態
- ➢例如，GC期間100毫秒的暫停時間意味着在這100毫秒期間內沒有應用程序線程是活動的。.
暫停時間優先，意味着儘量讓單次STW的時間最短： 0.1 + 0.1 + 0.1 + 0.1+0.1=0.5

高吞吐量較好由於這會讓應用程序的最終用戶感受只有應用程序線程在作「生產性」工做。直覺上，吞吐量越高程序運行越快。
低暫停時間（低延遲）較好由於從最終用戶的角度來看無論是GC仍是其餘緣由致使一個應用被掛起始終是很差的。這取決於應用程序的類型，有時候甚至短暫的200毫秒暫停均可能打斷終端用戶體驗。所以，具備低的較大暫停時間是很是重要的，特別是對於一一個交互式應用程序。
不幸的是」高吞吐量」和」低暫停時間」是一對相互競爭的目標（矛盾）。
- ➢由於若是選擇以吞吐量優先，那麼必然須要下降內存回收的執行頻率，可是這樣會致使GC須要更長的暫停時間來執行內存回收。
- ➢相反的，若是選擇以低延遲優先爲原則，那麼爲了下降每次執行內存回收時的暫停時間，也只能頻繁地執行內存回收，但這又引發了年輕代內存的縮誠和致使程序吞吐量的降低。
在設計（或使用） GC算法時，咱們必須肯定咱們的目標：一個GC算法只可能針對兩個目標之一（即只專一於較大吞吐量或最小暫停時間），或.嘗試找到一個兩者的折衷。
如今標準：在最大吞吐量優先的狀況下，下降停頓時間。

不一樣的垃圾回收器概述

垃圾收集機制是Java的招牌能力，極大地提升了開發效率。這固然也是面試的熱點。
那麼，Java常見的垃圾收集器有哪些？

垃圾收集器發展史

有了虛擬機，就必定須要收集垃圾的機制，這就是Garbage Collection，對應的產品咱們稱爲Garbage Collector.

1999年隨JDK1.3.1一起來的是串行方式的Serial GC，它是第一款GC。ParNew垃圾收集器是Serial收集器的多線程版本
2002年2月26日，Parallel GC和Concurrent Mark Sweep GC跟隨JDK1.4.2一塊兒發佈
Parallel GC在JDK6以後成爲HotSpot默認GC。
2012年，在JDK1.7u4版本中，G1可用。
2017年，JDK9中G1變成默認的垃圾收集器，以替代CMS。
2018年3月，JDK10中G1垃圾回收器的並行完整垃圾回收，實現並行性來改善最壞狀況下的延遲。
==------------分水嶺------------==
2018年9月，JDK11發佈。引入Epsilon垃圾回收器，又被稱爲"No一0p （無操做） "回收器。同時，引入ZGC：可伸縮的低延遲垃圾回收器（Experimental）。
2019年3月，JDK12發佈。加強G1，自動返回未用堆內存給操做系統。同時，引入Shenandoah GC：低停頓時間的GC （Experimental）。
2019年9月，JDK13發佈。加強ZGC，自動返回未用堆內存給操做系統。
2020年3月，JDK14發佈。刪除CMS垃圾回收器。擴展ZGC在macOS和Windows.上的應用

7款經典的垃圾收集器

串行回收器：Serial. Serial Old
並行回收器：ParNew. Parallel Scavenge. Parallel Old
併發回收器：CMS. G1

7款經典的垃圾收集器與垃圾分代之間的關係

新生代收集器： Serial、 ParNeW、Parallel Scavenge；
老年代收集器： Serial 0ld、 Parallel 0ld、 CMS；
整堆收集器： G1；

垃圾收集器的組合關係

兩個收集器間有連線，代表它們能夠搭配使用： Serial/Serial 01d、Serial/CMS、 ParNew/Serial 01d、ParNew/CMS、 Parallel Scavenge/Serial 01d、Parallel Scavenge/Parallel 0ld、G1；
其中Serial 0ld做爲CMS 出現"Concurrent Mode Failure"失敗的後備預案。 3.（紅色虛線）因爲維護和兼容性測試的成本，在JDK 8時將Serial+CMS、 ParNew+Serial 01d這兩個組合聲明爲廢棄（JEP 173），並在JDK 9中徹底取消了這些組合的支持（JEP214），即：移除。
（綠色虛線）JDK 14中：棄用Parallel Scavenge和Serial0ld GC組合（JEP366 ）
（青色虛線）JDK 14中：刪除CMS垃圾回收器（JEP 363）

爲何要有不少收集器個不夠嗎？由於Java的使用場景不少，移動端，服務器等。因此就須要針對不一樣的場景，提供不一樣的垃圾收集器，提升垃圾收集的性能。
雖然咱們會對各個收集器進行比較，但並不是爲了挑選一個最好的收集器出來。沒有一種放之四海皆準、任何場景下都適用的完美收集器存在，更加沒有萬能的收集器。因此咱們選擇的只是對具體應用最合適的收集器。

查看默認的垃圾收集器

一xx：+PrintCommandLineFlags：查看命令行相關參數（包含使用的垃圾收集器）
使用命令行指令： jinfo 一flag相關垃圾回收器參數進程ID

/**
 *  -XX:+PrintCommandLineFlags
 *
 *  -XX:+UseSerialGC:代表新生代使用Serial GC ，同時老年代使用Serial Old GC
 *
 *  -XX:+UseParNewGC：標明新生代使用ParNew GC
 *
 *  -XX:+UseParallelGC:代表新生代使用Parallel GC
 *  -XX:+UseParallelOldGC : 代表老年代使用 Parallel Old GC
 *  說明：兩者能夠相互激活
 *
 *  -XX:+UseConcMarkSweepGC：代表老年代使用CMS GC。同時，年輕代會觸發對ParNew 的使用
 */
public class GCUseTest {
    public static void main(String[] args) {
        ArrayList<byte[]> list = new ArrayList<>();

        while(true){
            byte[] arr = new byte[100];
            list.add(arr);
            try {
                Thread.sleep(10);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}

複製代碼

輸出

-XX:InitialHeapSize=268435456 -XX:MaxHeapSize=4294967296 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC 
複製代碼

或命令行
jdk8 使用的是parallel

jdk9 使用的是G1

Serial回收器:串行回收

Serial收集器是最基本、歷史最悠久的垃圾收集器了。JDK1.3以前回收新生代惟一的選擇。
Serial收集器做爲HotSpot中Client模式下的默認新生代垃圾收集器。
Serial收集器採用複製算法、串行回收和"Stop一 the一World"機制的方式執行內存回收。）
除了年輕代以外，Serial收集器還提供用於執行老年代垃圾收集的Serial 0ld收集器。 Serial 0ld收集器一樣也採用了串行回收和"Stop the World"機制，只不過內存回收算法使用的是標記一壓縮算法。
- ➢Serial 0ld是運行在Client模式下默認的老年代的垃圾回收器
- ➢Serial 0ld在Server模式下主要有兩個用途：①與新生代的ParallelScavenge配合使用; ②做爲老年代CMS收集器的後備垃圾收集方案
這個收集器是一個單線程的收集器，但它的「單線程」的意義並不只僅說明它只會使用一個CPU或一條收集線程去完成垃圾收集工做，更重要的是在它進行垃圾收集時，必須暫停其餘全部的工做線程，直到它收集結束（Stop The World ）。

優點

簡單而高效（與其餘收集器的單線程比），對於限定單個CPU的環境來講，Seria1收集器因爲沒有線程交互的開銷，專心作垃圾收集天然能夠得到最高的單線程收集效率。
- ➢運行在Client模式下的虛擬機是個不錯的選擇。
在用戶的桌面應用場景中，可用內存通常不大（幾十MB至一兩百MB），能夠在較短期內完成垃圾收集（幾十ms至一百多ms），只要不頻繁發生，使用串行回收器是能夠接受的。
在HotSpot虛擬機中，使用一XX： +UseSerialGC 參數能夠指定年輕代和老年代都使用串行收集器。
- 等價於新生代用Serial GC，且老年代用Serial 0ld GC
- 控制檯輸出 -XX:InitialHeapSize=268435456 -XX:MaxHeapSize=4294967296 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseSerialGC

總結

這種垃圾收集器你們瞭解，如今已經不用串行的了。並且在限定單核cpu才能夠用。如今都不是單核的了。
對於交互較強的應用而言，這種垃圾收集器是不能接受的。T通常在Javaweb應用程序中是不會採用串行垃圾收集器的。

ParNew回收器:並行回收

若是說Serial GC是年輕代中的單線程垃圾收集器，那麼ParNew收集器則是Serial收集器的多線程版本。
- ➢Par是Paralle1的縮寫，New：只能處理的是新生代
ParNew收集器除了採用並行回收的方式執行內存回收外，兩款垃圾收集器之間幾乎沒有任何區別。ParNew收集器在年輕代中一樣也是採用複製算法、"Stop一 the一World"機制。
ParNew是不少JVM運行在Server模式下新生代的默認垃圾收集器。
對於新生代，回收次數頻繁，使用並行方式高效。
對於老年代，回收次數少，使用串行方式節省資源。（CPU並行須要切換線程，串行能夠省去切換線程的資源）
因爲ParNew收集器是基於並行回收，那麼是否能夠判定ParNew收集器的回收效率在任何場景下都會比Serial收集器更高效？| I
- ➢ParNew 收集器運行在多CPU的環境下，因爲能夠充分利用多CPU、多核心等物理硬件資源優點，能夠更快速地完成垃圾收集，提高程序的吞吐量。
- ➢可是在單個CPU的環境下，ParNew收集器不比Serial收集器更高效。雖然Serial收集器是基於串行回收，可是因爲CPU不須要頻繁地作任務切換，所以能夠有效避免多線程交互過程當中產生的一些額外開銷。
由於除Serial外，目前只有ParNew GC能與CMS收集器配合工做
在程序中，開發人員能夠經過選項"一XX： +UseParNewGC"手動指定使用.ParNew收集器執行內存回收任務。它表示年輕代使用並行收集器，不影響老年代。
一XX：ParallelGCThreads 限制線程數量，默認開啓和CPU數據相同的線程數。.

Parallel回收器:吞吐量優先

HotSpot的年輕代中除了擁有ParNew收集器是基於並行回收的之外， Parallel Scavenge收集器一樣也採用了複製算法、並行回收和"Stop the World"機制。
那麼Parallel收集器的出現是否畫蛇添足？
- ➢和ParNew收集器不一樣，Parallel Scavenge收集器的目標則是==達到一個可控制的吞吐量==（Throughput），它也被稱爲吞吐量優先的垃圾收集器。
- ➢自適應調節策略也是Parallel Scavenge 與ParNew一個重要區別。
高吞吐量則能夠高效率地利用CPU 時間，儘快完成程序的運算任務|，主要適合在後臺運算而不須要太多交互的任務。所以，常見在服務器環境中使用。例如，那些執行批量處理、訂單處理、工資支付、科學計算的應用程序。
Parallel收集器在JDK1.6時提供了用於執行老年代垃圾收集的 Parallel 0ld收集器，用來代替老年代的Serial 0ld收集器。
Parallel 0ld收集器採用了標記一壓縮算法，但一樣也是基於並行回收和」Stop一the一World"機制。
在程序吞吐量優先的應用場景中，Parallel 收集器和Parallel 0ld收集器的組合，在Server模式下的內存回收性能很不錯。
在Java8中，默認是此垃圾收集器

參數配置

一XX： +UseParallelGC手動指定年輕代使用Parallel並行收集器執行內存回收任務。
一XX： +UseParallel0ldGc手動指定老年代都是使用並行回收收集器。
- 分別適用於新生代和老年代。默認jdk8是開啓的。
- 上面兩個參數，默認開啓一個，另外一個也會被開啓。（互相激活）
一XX： ParallelGCThreads設置年輕代並行收集器的線程數。通常地，最好與CPU數量相等，以免過多的線程數影響垃圾收集性能。
- 在默認狀況下，當CPU數量小於8個， Paralle lGCThreads 的值等於CPU數量。
- 當CPU數量大於8個， ParallelGCThreads的值等於3+[5*CPU_ Count]/8]
一XX ：MaxGCPau3eMillis設置垃圾收集器最大停頓時間（即STw的時間）。單位是毫秒。
- ➢爲了儘量地把停頓時間控制在MaxGCPauseMills之內，收集器在.工做時會調整Java堆大小或者其餘一些參數。
- ➢對於用戶來說，停頓時間越短體驗越好。可是在服務器端，咱們注重高併發，總體的吞吐量。因此服務器端適合Parallel，進行控制。➢該參數使用需謹慎。
一XX：GCTimeRatio垃圾收集時間佔總時間的比例（= 1 / （N + 1））用於衡量吞吐量的大小。
- ➢取值範圍（0， 100）。默認值99，也就是垃圾回收時間不超過1號。
- ➢與前一個一XX：MaxGCPauseMillis參數有必定矛盾性。暫停時間越長，Radio參數就容易超過設定的比例。
一XX： +UseAdaptiveSizePolicy設置Parallel Scavenge收集器具備自適應調節策略
- 在這種模式下，年輕代的大小、Eden和Survivor的比例、晉升老年代的對象年齡等參數會被自動調整，已達到在堆大小、吞吐量和停頓時間之間的平衡點。
- 在手動調優比較困難的場合，能夠直接使用這種自適應的方式，僅指定虛擬機的最大堆、目標的吞吐量（GCTimeRatio）和停頓時間（MaxGCPauseMills），讓虛擬機本身完成調優工做。

CMS回收器:低延遲

在JDK1.5時期， HotSpot推出了一款在強交互應用中幾乎可認爲有劃時代意義的垃圾收集器： CMS （Concurrent 一Mark 一 Sweep）收集器，這款收集器是HotSpot虛擬機中第一款真正意義上的併發收集器，它第一次實現了讓垃圾收集線程與用戶線程同時工做。
CMS收集器的關注點是儘量縮短垃圾收集時用戶線程的停頓時間。停頓時間越短（低延遲）就越適合與用戶交互的程序，良好的響應速度能提高用戶體驗。
- ➢目前很大一部分的Java應用集中在互聯網站或者B/s系統的服務端上，這類應用尤爲重視服務的響應速度，但願系統停頓時間最短，以給用戶帶來較好的體驗。CMS收集器就很是符合這類應用的需求。
CMS的垃圾收集算法採用標記一清除算法，而且也會" stop一the一world"
不幸的是，CMS 做爲老年代的收集器，卻沒法與JDK 1.4.0 中已經存在的新生代收集器Parallel Scavenge配合工做，因此在JDK 1. 5中使用CMS來收集老年代的時候，新生代只能選擇ParNew或者Serial收集器中的一個。
在G1出現以前，CMS使用仍是很是普遍的。一直到今天，仍然有不少系統使用CMS GC。

CMS整個過程比以前的收集器要複雜，整個過程分爲4個主要階段，即初始標記階段、併發標記階段、從新標記階段和併發清除階段。

初始標記（Initial一Mark）階段：在這個階段中，程序中全部的工做線程都將會由於. 「Stop一the一World"機制而出現短暫的暫停，這個階段的主要任務僅僅只是標記出GCRoots能直接關聯到的對象。一旦標記完成以後就會恢復以前被暫停的全部應用.線程。因爲直接關聯對象比較小，因此這裏的速度很是快。
併發標記（Concurrent一Mark）階段：從GC Roots的直接關聯對象開始遍歷整個對象圖的過程，這個過程耗時較長可是不須要停頓用戶線程，能夠與垃圾收集線程一塊兒併發運行。
從新標記（Remark）階段：因爲在併發標記階段中，程序的工做線程會和垃圾收集線程同時運行或者交叉運行，所以爲了修正併發標記期間，因用戶程序繼續運做而致使標記產生變更的那一部分對象的標記記錄，這個階段的停頓時間一般會比初始標記階段稍長一些，但也遠比並發標記階段的時間短。
併發清除（ Concurrent一Sweep）階段：此階段清理刪除掉標記階段判斷的已經死亡的對象，釋放內存空間。因爲不須要移動存活對象，因此這個階段也是能夠與用戶線程同時併發的

儘管CMS收集器採用的是併發回收（非獨佔式），可是在其初始化標記和再次標記這兩個階段中仍然須要執行「Stop一the一World」機制暫停程序中的工做線程，不過暫停時間並不會太長，所以能夠說明目前全部的垃圾收集器都作不到徹底不須要「Stop一the一World」，只是儘量地縮短暫停時間。
因爲最耗費時間的併發標記與併發清除階段都不須要暫停工做，因此總體的回收是低停頓的。
另外，因爲在垃圾收集階段用戶線程沒有中斷，因此在CMS回收過程當中，還應該確保應用程序用戶線程有足夠的內存可用。所以，CMS收集器不能像其餘收集器那樣等到老年代幾乎徹底被填滿了再進行收集，而是當堆內存使用率達到某一閾值時，便開始進行回收，以確保應用程序在CMS工做過程當中依然有足夠的空間支持應用程序運行。要是CMS運行期間預留的內存沒法知足程序須要，就會出現一次「Concurrent Mode Failure」失敗，這時虛擬機將啓動後備預案：臨時啓用Serial 0ld收集器來從新進行老年代的垃圾收集，這樣停頓時間就很長了。
CMS收集器的垃圾收集算法採用的是標記一清除算法，這意味着每次執行完內存回收後，因爲被執行內存回收的無用對象所佔用的內存空間極有多是不連續的一些內存塊，不可避免地將會產生一些內存碎片。那麼CMS在爲新對象分配內存空間時，將沒法使用指針碰撞（Bump the Pointer）技術，而只可以選擇空閒列表（Free List）執行內存分配。

有人會以爲既然Mark Sweep會形成內存碎片，那麼爲何不把算法換成Mark Compact呢？
答案其實很簡答，由於當併發清除的時候，用Compact整理內存的話，原來的用戶線程使用的內存還怎麼用呢？要保證用戶線程能繼續執行，前提的它運行的資源不受影響嘛。Mark Compact更適合「Stop the World」這種場景」下使用

·CMS的優勢： .

併發收集
低延遲

CMS的弊端：

1）會產生內存碎片，致使併發清除後，用戶線程可用的空間不足。在沒法分配大對象的狀況下，不得不提早觸發Full GC。
2） CMS收集器對CPU資源很是敏感。在併發階段，它雖然不會致使用戶停頓，可是會由於佔用了一部分線程而致使應用程序變慢，總吞吐量會下降。
3） CMS收集器沒法處理浮動垃圾。可能出現「Concurrent Mode Failure" 失敗而致使另外一次Full GC的產生。在併發標記階段因爲程序的工做線程和垃圾收集線程是同時運行或者交叉運行的，那麼在併發標記階段若是產生新的垃圾對象，CMS將沒法對這些垃圾對象進行標記，最終會致使這些新產生的垃圾對象沒有被及時回收，從而只能在下一次執行GC時釋放這些以前未被回收的內存空間。

參數設置

一XX：+UseConcMarkSweepGc 手動指定使用CMS收集器執行內存回收任務。
- ➢開啓該參數後會自動將一XX： +UseParNewGc打開。即： ParNew （Young區用） +CMS （0ld區用） +Serial 0ld的組合。
一XX：CMS1ni tiatingOccupanyFraction設置堆內存使用率的閾值，一旦達到該閾值，便開始進行回收。
- JDK5及之前版本的默認值爲68，即當老年代的空間使用率達到68號時，會執行一 .次CMS 回收。 JDK6 5及以上版本默認值爲92號
- ➢若是內存增加緩慢，則能夠設置一個稍大的值，大的閾值能夠有效下降CMS的觸發頻率，減小老年代回收的次數能夠較爲明顯地改善應用程序性能。反之，若是應用程序內存使用率增加很快，則應該下降這個閾值，以免頻繁觸發老年代串行收集器。所以經過該選項即可以有效下降Full GC的執行次數。
一XX： +UseCMSCompactAtFullCollection用於指定在執行完Full GC後對內存空間進行壓縮整理，以此避免內存碎片的產生。不過因爲內存壓縮整理過程沒法併發執行，所帶來的問題就是停頓時間變得更長了。
一XX：CMSFullGCsBeforeCompaction設置在執行多少次Full GC後對內存空間進行壓縮整理。
一XX：ParallelCMSThreads 設置CMS的線程數量。
- CMS 默認啓動的線程數是（ParallelGCThreads+3） /4， ParallelGCThreads是年輕代並行收集器的線程數。當CPU資源比較緊張時，受到CMs收集器線程的影響，應用程序的性能在垃圾回收階段可能會很是糟糕。

小結：

HotSpot有這麼多的垃圾回收器，那麼若是有人問，Serial GC、 Parallel GC、Concurrent Mark Sweep GC這三個GC有什麼不一樣呢？
請記住如下口令：
若是你想要最小化地使用內存和並行開銷，請選Serial GC；
若是你想要最大化應用程序的吞吐量，請選Parallel GC；
若是你想要最小化GC的中斷或停頓時間，請選CMS GC。

JDK 後續版本中CMS的變化

JDK9新特性： CMS被標記爲Deprecate了（JEP291）
- 若是對JDK 9及以上版本的HotSpot虛擬機使用參數一XX：+UseConcMarkSweepGC來開啓CMS收集器的話，用戶會收到一個警告信息，提示CMS將來將會被廢棄。
JDK14新特性：刪除CMS垃圾回收器（JEP363）
- 移除了CMS垃圾收集器，若是在JDK14中使用一XX： +UseConcMarkSweepGC的話，JVM不會報錯，只是給出一個warning信息，可是不會exit。JVM會自動回退以默認GC方式啓動JVM

G1回收器:區域化分代式

既然咱們已經有了前面幾個強大的GC，爲何還要發佈Garbage First （G1）GC？
緣由就在於應用程序所應對的業務愈來愈龐大、複雜，用戶愈來愈多，沒有GC就不能保證應用程序正常進行，而常常形成STW的GC又跟不上實際的需求，因此纔會不斷地嘗試對GC進行優化。G1 （Garbage一First）垃圾回收器是在Java7 update4以後引入的一個新的垃圾回收器，是當今收集器技術發展的最前沿成果之一。
與此同時，爲了適應如今不斷擴大的內存和不斷增長的處理器數量，進一步下降暫停時間（pause time），同時兼顧良好的吞吐量。
==官方給G1設定的目標是在延遲可控的狀況下得到儘量高的吞吐量，因此才擔當起「全功能收集器」的重任與指望==

爲何名字叫作Garbage First （G1）呢？

由於G1是一個並行回收器，它把堆內存分割爲不少不相關的區域（Region）（物理上不連續的）。使用不一樣的Region來表示Eden、倖存者0區，倖存者1區，老年代等。
G1 GC有計劃地避免在整個Java 堆中進行全區域的垃圾收集。G1跟蹤各個Region 裏面的垃圾堆積的價值大小（回收所得到的空間大小以及回收所需時間的經驗值），在後臺維護一個優先列表，每次根據容許的收集時間，優先回收價值最大的Region。
因爲這種方式的側重點在於回收垃圾最大量的區間（Region），因此咱們給G1一個名字：垃圾優先（Garbage First）。
G1 （Garbage一First）是一款面向服務端應用的垃圾收集器，主要針對配備多核CPU及大容量內存的機器，以極高機率知足GC停頓時間的同時，還兼具高吞吐量的性能特徵。
在JDK1. 7版本正式啓用，移除了Experimental的標識，是JDK 9之後的默認垃圾回收器，取代了CMS回收器以及Parallel + Parallel 0ld組合。被Oracle官方稱爲「全功能的垃圾收集器」。
與此同時，CMS已經在JDK 9中被標記爲廢棄（deprecated）。在jdk8中還不是默認的垃圾回收器，須要使用一XX： +UseG1GC來啓用。

優點

與其餘GC收集器相比，G1使用了全新的分區算法，其特色以下所示：

並行與併發
- ➢並行性： G1在回收期間，能夠有多個Gc線程同時工做，有效利用多核計算能力。此時用戶線程STW
- ➢併發性： G1擁有與應用程序交替執行的能力，部分工做能夠和應用程序同時執行，所以，通常來講，不會在整個回收階段發生徹底阻塞應用程序的狀況
分代收集
- ➢從分代上看，G1依然屬於分代型垃圾回收器，它會區分年輕代和老年代，年輕代依然有Eden區和Survivor區。但從堆的結構，上看，它不要求整個Eden區、年輕代或者老年代都是連續的，也再也不堅持固定大小和固定數量。
- ➢將堆空間分爲若干個區域（Region），這些區域中包含了邏輯上的年輕代和老年代。
- ➢和以前的各種回收器不一樣，它同時兼顧年輕代和老年代。對比其餘回收器，或者工做在年輕代，或者工做在老年代；
空間整合
- ➢CMS：「標記一清除」算法、內存碎片、若干次Gc後進行一次碎片整理
- ➢G1將內存劃分爲一個個的region。內存的回收是以region做爲基本單位的.Region之間是複製算法，但總體上實際可看做是標記一壓縮（Mark一Compact）算法，兩種算法均可以免內存碎片。這種特性有利於程序長時間運行，分配大對象時不會由於沒法找到連續內存空間而提早觸發下一次GC。尤爲是當Java堆很是大的時候，G1的優點更加明顯。
可預測的停頓時間模型（即：軟實時soft real一time）這是G1相對於CMS的另外一大優點，G1除了追求低停頓外，還能創建可預測的停頓時間模型，能讓使用者明確指定在一個長度爲M毫秒的時間片斷內，消耗在垃圾收集上的時間不得超過N毫秒。
- ➢因爲分區的緣由，G1能夠只選取部分區域進行內存回收，這樣縮小了回收的範圍，所以對於全局停頓狀況的發生也能獲得較好的控制。
- ➢G1跟蹤各個Region裏面的垃圾堆積的價值大小（回收所得到的空間大小以及回收所需時間的經驗值），在後臺維護一個優先列表，每次根據容許的收集時間，優先回收價值最大的Region。保證了G1 收集器在有限的時間內能夠獲取儘量高的收集效率。
- ➢相比於CMSGC，G1未必能作到CMS在最好狀況下的延時停頓，可是最差狀況要.好不少。

缺點

相較於CMS，G1還不具有全方位、壓倒性優點。好比在用戶程序運行過程當中，G1不管是爲了垃圾收集產生的內存佔用（Footprint）仍是程序運行時的額外執行負載（overload）都要比CMS要高。
從經驗上來講，在小內存應用上CMS的表現大機率會優於G1，而G1在大內存應用，上則發揮其優點。平衡點在6一8GB之間。

參數設置

一XX：+UseG1GC 手動指定使用G1收集器執行內存回收任務。
一XX：G1HeapRegionSize 設置每一個Region的大小。值是2的冪，範圍是1MB 到32MB之間，目標是根據最小的Java堆大小劃分出約2048個區域。默認是堆內存的1/2000。
一XX：MaxGCPauseMillis 設置指望達到的最大Gc停頓時間指標（JVM會盡力實現，但不保證達到）。默認值是200ms
一xX：ParallelGCThread 設置sTw.工做線程數的值。最多設置爲8
一XX：ConcGCThreads 設置併發標記的線程數。將n設置爲並行垃圾回收線程數（ParallelGCThreads）的1/4左右。
一XX：Ini tiatingHeapOccupancyPercent 設置觸發併發GC週期的Java堆佔用率閾值。超過此值，就觸發GC。默認值是45。

G1回收器的常見操做步驟

G1的設計原則就是簡化JVM性能調優，開發人員只須要簡單的三步便可完成調優：

第一步：開啓G1垃圾收集器
第二步：設置堆的最大內存
第三步：設置最大的停頓時間

G1中提供了三種垃圾回收模式： YoungGC、 Mixed GC和Full GC，在不一樣的條件下被觸發。

適用場景

面向服務端應用，針對具備大內存、多處理器的機器。（在普通大小的堆裏表現並不.驚喜）
最主要的應用是須要低GC延遲，並具備大堆的應用程序提供解決方案；
如：在堆大小約6GB或更大時，可預測的暫停時間能夠低於0.5秒；（ G1經過每次只清理一部分而不是所有的Region的增量式清理來保證每次GC停頓時間不會過長）。
用來替換掉JDK1.5中的CMS收集器；在下面的狀況時，使用G1可能比CMS好：
①超過50%的Java堆被活動數據佔用；
②對象分配頻率或年代提高頻率變化很大；
③GC停頓時間過長（長於0. 5至1秒）。
HotSpot垃圾收集器裏，除了G1之外，其餘的垃圾收集器使用內置的JVM線程執行 GC的多線程操做，而G1 GC能夠採用應用線程承擔後臺運行的GC工做，即當JVM的GC線程處理速度慢時，系統會調用應用程序線程幫助加速垃圾回收過程。

分區region,化整爲零

使用G1收集器時，它將整個Java堆劃分紅約2048個大小相同的獨立Region塊，每一個Region塊大小根據堆空間的實際大小而定，總體被控制在1MB到32MB之間，且爲2的N次冪，即1MB， 2MB， 4MB， 8MB， 1 6MB， 32MB。能夠經過一 XX：G1HeapRegionSize設定。全部的Region大小相同，且在JVM生命週期內不會被改變。
雖然還保留有新生代和老年代的概念，但新生代和老年代再也不是物理隔離的了，它們都是一部分Region （不須要連續）的集合。經過Region的動態分配方式實現邏輯_上的連續。

一個region 有可能屬於Eden， Survivor 或者0ld/Tenured 內存區域。可是一個region只可能屬於一個角色。圖中的E表示該region屬於Eden內存區域，s表示屬於Survivor內存區域，0表示屬於0ld內存區域。圖中空白的表示未使用的內存空間。
G1垃圾收集器還增長了一種新的內存區域，叫作Humongous內存區域，如圖中的H塊。主要用於存儲大對象，若是超過1. 5個region，就放到H。
設置H的緣由：
- 對於堆中的大對象，默認直接會被分配到老年代，可是若是它是一個短時間存在的大對象，就會對垃圾收集器形成負面影響。爲了解決這個問題，G1劃分了一個Humongous區，它用來專門存放大對象。若是一個H區裝不下一個大對象，那麼G1會尋找連續的H區來存儲。爲了能找到連續的H區，有時候不得不啓動Full GC。G1的大多數行爲都把H區做爲老年代的一部分來看待。

G1回收器垃圾回收過程

G1 GC的垃圾回收過程主要包括以下三個環節：

年輕代GC （Young GC ）
老年代併發標記過程（ Concurrent Marking）
混合回收（Mixed GC ）
（若是須要，單線程、獨佔式、高強度的Full GC仍是繼續存在的。它針對GC的評估失敗提供了一種失敗保護機制，即強力回收。）
順時針， young gc 一> young gc + concurrent mark 一> Mixed GC順序，進行垃圾回收。
應用程序分配內存，當年輕代的Eden區用盡時開始年輕代回收過程； G1的年輕代收集階段是一個並行的獨佔式收集器。在年輕代回收期，G1 GC暫停全部應用程序線程，啓動多線程執行年輕代回收。而後從年輕代區間移動存活對象到Survivor區間或者老年區間，也有多是兩個區間都會涉及。
當堆內存使用達到必定值（默認45%）時，開始老年代併發標記過程。
標記完成馬.上開始混合回收過程。對於一個混合回收期，G1 GC從老年區間移動存活對象到空閒區間，這些空閒區間也就成爲了老年代的一部分。和年輕代不一樣，老年代的G1回收器和其餘GC不一樣，G1的老年代回收器不須要整個老年代被回收，一次只須要掃描/回收一小部分老年代的Region就能夠了。同時，這個老年代Region是和年輕代一塊兒被回收的。
舉個例子：一個web服務器，Java進程最大堆內存爲4G，每分鐘響應1500個請求，每45秒鐘會新分配大約2G的內存。G1會每45秒鐘進行一次年輕代回收，每31 個小時整個堆的使用率會達到45號，會開始老年代併發標記過程，標記完成後開始四到五次的混合回收。

記憶集與寫屏障

一個對象被不一樣區域引用的問題(分代引用問題)
一個Region不多是孤立的，一個Region中的對象可能被其餘任意Region中對象引用，判斷對象存活時，是否須要掃描整個Java堆才能保證準確？
在其餘的分代收集器，也存在這樣的問題（而G1更突出）
回收新生代也不得不一樣時掃描老年代？
這樣的話會下降MinorGC的效率；
·解決方法：
- ➢不管G1仍是其餘分代收集器，JVM都是使用RememberedSet來避免全局掃描：
- ➢每一個Region都有一個對應的Remembered Set；
- ➢每次Reference類型數據寫操做時，都會產生一個Write Barrier暫時中斷操做； .
- ➢而後檢查將要寫入的引用指向的對象是否和該Reference類型數據在不一樣的Region （其餘收集器：檢查老年代對象是否引用了新生代對象）；
- ➢若是不一樣，經過CardTable把相關引用信息記錄到引用指向對象的所在Region對應的Remembered Set中；
- ➢當進行垃圾收集時，在GC根節點的枚舉範圍加入Remembered Set；就能夠保證不進行全局掃描，也不會有遺漏。

G1回收過程詳解

1. 年輕代GC

JVM啓動時，G1 先準備好Eden區，程序在運行過程當中不斷建立對象到Eden區，當Eden空間耗盡時，G1會啓動一次年輕代垃圾回收過程。
年輕代垃圾回收只會回收Eden區和Survivor區。
YGC時，首先G1中止應用程序的執行（Stop一The一World），G1建立回收集（Collection Set），回收集是指須要被回收的內存分段的集合，年輕代回收過程的回收集包含年輕代Eden區和Survivor區全部的內存分段。
而後開始以下回收過程：
- 第一階段，掃描根。
  根是指static變量指向的對象，正在執行的方法調用鏈條上的局部變量等。根引用連同RSet記錄的外部引用做爲掃描存活對象的入口。
- 第二階段，更新RSet.
  處理dirty card queue（見備註）中的card，更新RSet。此階段完成後，RSet可以準確的反映老年代對所在的內存分段中對象的引用。
  - dirty card queue: 對於應用程序的引用賦值語句object.field=object，JVM會在以前和以後執行特殊的操做以在dirty card queue中入隊一個保存了對象引用信息的card。在年輕代回收的時候， G1會對Dirty Card Queue中全部的card進行處理，以更新RSet，保證RSet實時準確的反映引用關係。那爲何不在引用賦值語句處直接更新RSet呢？這是爲了性能的須要，RSet的處理須要線程同步，開銷會很大，使用隊列性能會好不少。
- 第三階段，處理RSet。
  識別被老年代對象指向的Eden中的對象，這些被指向的Eden中的對象被認爲是存活的對象。
- 第四階段，複製對象。
  此階段，對象樹被遍歷，Eden區內存段中存活的對象會被複制到Survivor區中空的內存分段，Survivor區內存段中存活的對象若是年齡未達閾值，年齡會加1，達到閥值會被會被複制到01d區中空的內存分段。若是Survivor空間不夠，Eden空間的部分數據會直接晉升到老年代空間。
- 第五階段，處理引用。
  處理Soft，Weak， Phantom， Final， JNI Weak等引用。最終Eden空間的數據爲空，GC中止工做，而目標內存中的對象都是連續存儲的，沒有碎片，因此複製過程能夠達到內存整理的效果，減小碎片。

2. 併發標記過程

初始標記階段：標記從根節點直接可達的對象。這個階段是STW的，而且會觸發一.次年輕代GC。
根區域掃描（Root Region Scanning）： G1 GC掃描Survivor區直接可達的老年代區域對象，並標記被引用的對象。這一過程必須在young GC以前完成。
併發標記（Concurrent Marking）：在整個堆中進行併發標記（和應用程序併發執行），此過程可能被young GC中斷。在併發標記階段，若發現區域對象中的全部對象都是垃圾，那這個區域會被當即回收。同時，併發標記過程當中，會計算每一個區域的對象活性（區域中存活對象的比例）。
再次標記（Remark）：由於應用程序持續進行，須要修正上一次的標記結果。是STW的。G1中採用了比CMS更快的初始快照算法：snapshot一at一the一beginning （SATB）。
獨佔清理（cleanup，STW）：計算各個區域的存活對象和GC回收比例，並進行排序，識別能夠混合回收的區域。爲下階段作鋪墊。是STW的。
- ➢這個階段並不會實際上去作垃圾的收集
併發清理階段：識別並清理徹底空閒的區域。

3. 混合回收

當愈來愈多的對象晉升到老年代oldregion時，爲了不堆內存被耗盡，虛擬機會觸發一個混合的垃圾收集器，即Mixed GC，該算法並非一個0ldGC，除了回收整個Young Region，還會回收一部分的0ldRegion。這裏須要注意：是一部分老年代，而不是所有老年代。能夠選擇哪些0ldRegion進行收集，從而能夠對垃圾回收的耗時時間進行控制。也要注意的是Mixed GC並非Fu1l GC。

併發標記結束之後，老年代中百分百爲垃圾的內存分段被回收了，部分爲垃圾的內存分段被計算了出來。默認狀況下，這些老年代的內存分段會分8次（能夠經過一XX： G1MixedGCCountTarget設置）被回收。
混合回收的回收集（Collection Set）包括八分之一的老年代內存分段，Eden區內存分段，Survivor區內存分段。混合回收的算法和年輕代回收的算法徹底同樣，只是回收集多了老年代的內存分段。具體過程請參考上面的年輕代回收過程。
因爲老年代中的內存分段默認分8次回收，G1會優先回收垃圾多的內存分段。垃圾佔內存分段比例越高的，越會被先回收。而且有一個閾值會決定內存分段是否被回收，一xX： G1MixedGCLiveThresholdPercent，默認爲65%，意思是垃圾佔內存分段比例要達到65%纔會被回收。若是垃圾佔比過低，意味着存活的對象佔比高，在複製的時候會花費更多的時間。
混合回收並不必定要進行8次。有一個閾值一Xx： G1HeapWastePercent，默認值爲10%，意思是容許整個堆內存中有10%的空間被浪費，意味着若是發現能夠回收的垃圾佔堆內存的比例低於10%，則再也不進行混合回收。由於GC會花費不少的時間可是回收到的內存卻不多。

4. Full GC

G1的初衷就是要避免Full GC的出現。可是若是上述方式不能正常工做，G1會中止應用程序的執行（Stop一 The一World），使用單線程的內存回收算法進行垃圾回收，性能會很是差，應用程序停頓時間會很長。
要避免Full GC的發生，一旦發生須要進行調整。何時會發生Full GC呢？好比堆內存過小，當G1在複製存活對象的時候沒有空的內存分段可用，則會回退到full gc，這種狀況能夠經過增大內存解決。
致使G1Full GC的緣由可能有兩個：

1.Evacuation的時候沒有足夠的to一 space來存放晉升的對象；
2.併發處理過程完成以前空間耗盡。

補充

從Oracle官方透露出來的信息可獲知，回收階段（Evacuation）其實.本也有想過設計成與用戶程序一塊兒併發執行，但這件事情作起來比較複雜，考慮到G1只是回收一部分Region，停頓時間是用戶可控制的，因此並不迫切去實現，而選擇把這個特性放到了G1以後出現的低延遲垃圾收集器（即ZGC）中。另外，還考慮到G1不是僅僅面向低延遲，停頓用戶線程可以最大幅度提升垃圾收集效率，爲了保證吞吐量因此才選擇了徹底暫停用戶線程的實現方案。

優化建議

年輕代大小
- ➢避免使用一Xmn或一XX：NewRatio等相關選項顯式設置年輕代大小➢固定年輕代的大小會覆蓋暫停時間目標
暫停時間目標不要太過嚴苛
- G1 GC的吞吐量目標是90%的應用程序時間和10%的垃圾回收時間
- 評估G1 GC的吞吐量時，暫停時間目標不要太嚴苛。目標太過嚴苛表示你願意承受更多的垃圾回收開銷，而這些會直接影響到吞吐量。

垃圾回收器總結

截止JDK 1.8，一共有7款不一樣的垃圾收集器。每一款不一樣的垃圾收集器都有不一樣的特色，在具體使用的時候，須要根據具體的狀況選用不一樣的垃圾收集器。

不一樣廠商、不一樣版本的虛擬機實現差異很大。HotSpot 虛擬機在JDK7/8後全部收集器及組合（連線），以下圖：

1.兩個收集器間有連線，代表它們能夠搭配使用： Serial/Serial 0ld、Serial /CMS、ParNew/Serial 0ld、ParNew/CMS、 Parallel Scavenge/Serial 01d、Parallel Scavenge/Parallel 0ld、G1；
2.其中Serial 0ld做爲CMS出現"Concurrent Mode Failure"失敗的後備預案。
3.（紅色虛線）因爲維護和兼容性測試的成本，在JDK 8時將Serial+CMS、 ParNew+Serial 0ld這兩個組合聲明爲Deprecated （JEP 173），並在JDK 9中徹底取消了這些組合的支持（JEP214），即：移除。
4.（綠色虛線）JDK 14中：棄用ParallelScavenge 和Serial0ld GC組合（JEP 366）
5.（青色虛線）JDK 14中：刪除CMS垃圾回收器（JEP 363 ） GC發展階段： Serial => Parallel （並行） => CMS （併發） => G1 => ZGC

怎麼選擇垃圾回收器

Java垃圾收集器的配置對於JVM優化來講是一個很重要的選擇，選擇合適的垃圾收集器可讓JVM的性能有一個很大的提高。
怎麼選擇垃圾收集器？
- 1.優先調整堆的大小讓JVM自適應完成。
- 2.若是內存小於100M，使用串行收集器
- 3.若是是單核、單機程序，而且沒有停頓時間的要求，串行收集器
- 4.若是是多CPU、須要高吞吐量、容許停頓時間超過1秒，選擇並行或者JVM本身選擇
- 5.若是是多CPU、追求低停頓時間，需快速響應（好比延遲不能超過1秒，如互聯網應用），使用併發收集器
- 官方推薦G1，性能高。如今互聯網的項目，基本都是使用G1。
最後須要明確一一個觀點：
- 1.沒有最好的收集器，更沒有萬能的收集；
- 2.調優永遠是針對特定場景、特定需求，不存在一勞永逸的收集器

GC日誌分析

經過閱讀GC日誌，咱們能夠了解Java虛擬機內存分配與回收策略。內存分配與垃圾回收的參數列表

一XX： +PrintGC 輸出Gc日誌。相似：一verbose：gc
一XX： +PrintGCDetails 輸出GC的詳細日誌
一XX： +PrintGCTimeStamps 輸出GC的時間戳（以基準時間的形式）
一XX： +PrintGCDateStamps輸出GC的時間戳（以日期的形式，如2013一05一04T21 ： 53：59.234+0800 ）
一XX： +PrintHeapAtGC 在進行GC的先後打印出堆的信息
一Xloggc：. . /logs/gc. log日誌文件的輸出路徑

+PrintGC

打開GC日誌：一verbose：gc
這個只會顯示總的GC堆的變化，以下：

[GC （Allocation Failure） 80832K一>19298K（227840K），0.0084018 secs]
[GC （Metadata GC Threshold） 109499K一>21465K （228352K），0.0184066 secs]
[Full GC （Metadata GC Threshold） 21 465K一>16716K （201728K），0.0619261 secs ]
複製代碼

參數解析：

GC、Full GC： GC的類型，GC只在新生代上進行，Full GC包括永生代，新生代， 老年代。
Allocation Failure： GC發生的緣由。
80832K一> 19298K：堆在GC前的大小和GC後的大小。
228840k：如今的堆大小。
0.0084018 secs： GC持續的時間。
複製代碼

PrintGCDetails

-打開GC日誌： 一verbose：gc一 XX： +PrintGCDetaiis

輸入信息以下：

[GC （Allocation Failure） [ PSYoungGen： 70640K一> 10116K（141312K） ] 80541K一>20017K （227328K），0.0172573 secs] [Times： user=0.03 sys=0.00， real=0.02 secs ]
[GC （Metadata GC Threshold） [PSYoungGen：98859K一>8154K（142336K） ] 108760K一>21261K （228352K），
0.0151573 secs] [Times： user=0.00 sys=0.01， real=0.02 secs]
[Full GC （Metadata GC Threshold） [PSYoungGen： 8154K一>0K（142336K） ] [ParOldGen： 13107K一>16809K（62464K） ] 21261K一>16809K （204800K），[Metaspace： 20599K一>20599K （1067008K） ]，0.0639732 secs]
[Times： user=0.14 sys=0.00， real=0.06 secs]
複製代碼

參數解析：

GC，Full FC：一樣是GC的類型
Allocation Failure： GC緣由
PSYoungGen：使用了Parallel Scavenge並行垃圾收集器的新生代GC先後大小的變化
ParOldGen：使用了Parallel Old並行垃圾收集器的老年代Gc先後大小的變化
Metaspace： 元數據區GC先後大小的變化，JDK1.8中引入了 元數據區以替代永久代
xxx secs ： 指Gc花費的時間
Times： user： 指的是垃圾收集器花費的全部CPU時間，sys： 花費在等待系統調用或系統事件的時間， real ：GC從開始到結束的時間，包括其餘進程佔用時間片的實際時間。
複製代碼

PrintGCTimeStamps

打開GC日誌： 一verbose：gc 一XX： +PrintGCDetails 一XX：+PrintGCTimeStamps 一 XX： +PrintGCDateStamps
輸入信息以下：

2019一09一24T22：15：24.518+0800：3.287： [GC（Allocation Failure） [ PSYoungGen： 1361 62K一>5113K（136192K） ] 141425K一>17632K （222208K） ，0.0248249 secs] [Times： user=0.05sys=0.00， real=0.03 secs ]
2019一09一24T22：15：25.559+0800：4.329： [ GC（Metadata GC Threshold）[PSYoungGen：97578K一>10068K（274944K） ] 110096K一>22658K （360960K），0.0094071 secs]
[Times： user=0. 00sys=0.00， real=0. 01 secs]
2019一09一24T22：15：25.569+0800：4.338： [Full GC （Metadata GC Threshold）[ PSYoungGen：10068K一>0K（274944K） ] [ ParoldGen： 12590K一>13564K （56320K） ] 22658K一>13564K （331264K） ，
[Metaspace： 20590K一>20590K（1067008K）]， 0. 0494875 secs]
[Times： user=0.17 sys=0. 02，real=0.05 secs ]     
複製代碼

說明：帶上了日期和時間

補充說明

"[GC"和"[Full GC"說明了此次垃圾收集的停頓類型，若是有"Full"則說明GC發生了"StopThe World"
使用Serial收集器在新生代的名字是De fault New Generation，所以顯示的是" [DefNew"
使用ParNew收集器在新生代的名字會變成" 【ParNew"，意思是"Parallel New Generation"
使用Parallel Scavenge收集器在新生代的名字是" 【PSYoungGen"
老年代的收集和新生代道理同樣，名字也是收集器決定的
使用G1收集器的話，會顯示爲"garbage一 first heap"
Allocation Failure 代表本次引發GC的緣由是由於在年輕代中沒有足夠的空間可以存儲新的數據了。
[PSYoungGen： 5986K一>696K（8704K）] 5986K一> 704K （9216K）中括號內： GC回收前年輕代大小，回收後大小，（年輕代總大小）括號外： GC回收前年輕代和老年代大小，回收後大小，（年輕代和老年代總大小）
user表明用戶態回收耗時，sys 內核態回收耗時， rea實際耗時。因爲多核的緣由，時間總和可能會超過real時間

Minor GC

Full GC

例

/**
 * 在jdk7 和 jdk8中分別執行
 * -verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:+UseSerialGC
 */
public class GCLogTest1 {
    private static final int _1MB = 1024 * 1024;

    public static void testAllocation() {
        byte[] allocation1, allocation2, allocation3, allocation4;
        allocation1 = new byte[2 * _1MB];
        allocation2 = new byte[2 * _1MB];
        allocation3 = new byte[2 * _1MB];
        allocation4 = new byte[4 * _1MB];
    }

    public static void main(String[] agrs) {
        testAllocation();
    }
}
複製代碼

日誌分析工具使用

能夠用一些工具去分析這些gc日誌。
經常使用的日誌分析.工具備： GCViewer、GCEasy、GCHisto、GCLogViewer 、Hpjmeter、garbagecat等。

垃圾回收器的新發展

GC仍然處於飛速發展之中，目前的默認選項G1 GC在不斷的進行改進，不少咱們原來認爲的缺點，例如串行的Full GC、Card Table掃描的低效等，都已經被大幅改進，例如，JDK 10之後，Fu1l GC已是並行運行，在不少場景下，其表現還略優於Parallel GC的並行Full GC實現。
即便是Serial GC，雖然比較古老，可是簡單的設計和實現未必就是過期的，它自己的開銷，無論是GC相關數據結構的開銷，仍是線程的開銷，都是很是小的，因此隨着雲計算的興起，在Serverless等新的應用場景下，Serial GC找到了新的舞臺。
比較不幸的是CMS GC，由於其算法的理論缺陷等緣由，雖然如今還有很是大的用戶羣體，但在JDK9中已經被標記爲廢棄，並在JDK14版本中移除。

JDK11 新特性

JEP318 : Epsilon: A No一Op Garbage Collector (Epsilon 垃圾回收器,"No一Op (無操做) "回收器) http: / /openidk.java.net/ieps/318
JEP333: ZGC: A Scalable Low一 Latency ;Garbage Collector (Experimental) ( ZGC:可伸縮的低延退竝阪回收器，處於試驗性階段)

Open JDK12的Shenandoah GC

如今G1回收器已成爲默認回收器好幾年了。
咱們還看到了引入了兩個新的收集器： ZGC （ JDK11出現）和Shenandoah（Open JDK12）。
- ➢主打特色：低停頓時間

Open JDK12 的Shenandoah GC：低停頓時間的GC （實驗性）

Shenandoah，無疑是衆多GC中最孤獨的一個。是第一款不禁Oracle公司團隊領導開發的HotSpot垃圾收集器。不可避免的受到官方的排擠。好比號稱OpenJDK和OracleJDK沒有區別的Oracle公司仍拒絕在OracleJDK12中支持Shenandoah。
Shenandoah垃圾回收器最初由RedHat進行的一項垃圾收集器研究項目PauselessGC的實現，旨在針對JVM上的內存回收實現低停頓的需求。在2014年貢獻給OpenJDK。
Red Hat研發Shenandoah團隊對外宣稱，Shenandoah垃圾回收器的暫停時間與堆大小無關，這意味着不管將堆設置爲200MB仍是200GB，99.9%的目標均可以把垃圾收集的停頓時間限制在十毫秒之內。不過實際使用性能將取決於實際工做堆的大小和工做負載。
這是RedHat在2016年發表的論文數據，測試內容是使用Es對200GB的維基百科數據進行索引。從結果看：
- 停頓時間比其餘幾款收集器確實有了質的飛躍，但也未實現最大停頓時間控制在十毫秒之內的目標。
- 而吞吐量方面出現了明顯的降低，總運行時間是全部測試收集器裏最長的。
Shenandoah GC的弱項：高運行負擔下的吞吐量降低。
Shenandoah GC的強項：低延遲時間。

革命性的ZGC

官網連接
ZGC與Shenandoah目標高度類似，在儘量對吞吐量影響不大的前提下，實如今任意堆內存大小下均可以把垃圾收集的停頓時間限制在十毫秒之內的低延遲。
《深刻理解Java虛擬機》一書中這樣定義ZGC： ZGC收集器是一款基於Region內存佈局的，（暫時）不設分代的，使用了讀屏障、染色指針和內存多重映射等技術來實現可併發的標記一壓縮算法的，以低延遲爲首要目標的一款垃圾收集器。
ZGC的工做過程能夠分爲4個階段：併發標記一併發預備重分配一併發重分配一併發重映射等。
ZGC幾乎在全部地方併發執行的，除了初始標記的是sTW的。因此停頓時間.幾乎就耗費在初始標記上，這部分的實際時間是很是少的。

測試數據如圖:
劣勢比較

優點比較

在ZGC的強項停頓時間測試上，它絕不留情的將Parallel、G1拉開了兩個數量級的差距。不管平均停頓、958停頓、998停頓、99. 98停頓，仍是最大停頓時間，ZGC 都能絕不費勁控制在10毫秒之內。

JDK14新特性

JEP 364： ZGC應用在macOS上
JEP 365： ZGC應用在windows上 JDK14以前，ZGC僅Linux才支持

儘管許多使用ZGC的用戶都使用類Linux的環境，但在Windows和macOS 上，人們也須要ZGC進行開發部署和測試。許多桌面應用也能夠從ZGC中受益。所以，ZGC特性被移植到了Windows和macOs.上。
如今mac或Windows 上也能使用zGC了，示例以下：一XX： +Unloc kExperimentalVMOptions 一XX： +UseZGC .