【詳解】JVM——垃圾回收之垃圾收集器

目錄

• 1. 串行垃圾收集器
• • • a. 編寫測試代碼
    • b. 設定垃圾回收為串行收集器
• 2. 并行垃圾收集器（ParNew）
• 3. ParallelGC垃圾收集器(一般使用這個)
• 4. CMS垃圾收集器（重點）
• 5. G1垃圾收集器（重點）
• • • a. Young GC
    • b. Mixed GC
    • c. 對于G1垃圾收集器優化建議
• 可視化GC日志分析工具

前面我們講了垃圾回收的算法，還需要有具體的實作，在jvm中，實作了多種垃圾收集器，包括：串行垃圾收集器、并行垃圾收集器、CMS（并發）垃圾收集器、G1垃圾收集器，接下來，我們一個個的了解學習。

1. 串行垃圾收集器

• 串行垃圾收集器，是指使用

  單線程

  進行垃圾回收，垃圾回收時，隻有一個線程在工作，并且java應用中的所有線程都要暫停，等待垃圾回收的完成。這種現象稱之為

  STW（Stop-The-World）

  。

• 對于互動性較強的應用而言，這種垃圾收集器是不能夠接受的。

  一般在Javaweb應用中是不會采用該收集器的。

• Serial是新生代的，Serial Old是老年代的

a. 編寫測試代碼

public class TestGC {
    //不斷的産生新的對象，随機的廢棄對象，模拟程式正常運作
    public static void main(String[] args) throws Exception {
        List<Object> list = new ArrayList<Object>();
        while (true){
            int sleep = new Random().nextInt(100);
            if(System.currentTimeMillis() % 2 ==0){
                list.clear();
            }else{
                for (int i = 0; i < 10000; i++) {
                    Properties properties = new Properties();
                    properties.put("key_"+i, "value_" +
                            System.currentTimeMillis() + i);
                    list.add(properties);
                }
            }
            // System.out.println("list大小為：" + list.size());
            Thread.sleep(sleep);
        }
    }
}
           

b. 設定垃圾回收為串行收集器

在程式運作參數中添加2個參數，如下：

• -XX:+UseSerialGC

  指定年輕代和老年代都使用串行垃圾收集器

• -XX:+PrintGCDetails

  列印垃圾回收的詳細資訊

為了測試GC，将堆的初始和最大記憶體都設定為16M

• -Dfile.encoding=UTF-8 -XX:+UseSerialGC -XX:+PrintGCDetails -Xms16m -Xmx16m

  

啟動程式，可以看到下面資訊：

[GC (Allocation Failure) [DefNew: 4416K‐>512K(4928K), 0.0046102 secs]

4416K‐>1973K(15872K), 0.0046533 secs] [Times: user=0.00 sys=0.00,

real=0.00 secs]

[Full GC (Allocation Failure) [Tenured: 10944K‐>3107K(10944K), 0.0085637

secs] 15871K‐>3107K(15872K), [Metaspace: 3496K‐>3496K(1056768K)],

0.0085974 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]

GC日志資訊解讀：

• GC後面的括号表示執行GC的原因，Allocation Failure代表申請失敗
• DefNew表示使用的是

  串行垃圾收集器

• 年輕代的記憶體GC前後的大小：4416K->512K(4928K)
• 表示年輕代GC前，占有4416K記憶體，GC後，占有512K記憶體，總大小4928K
• 0.0046102 secs表示，GC所用的時間，機關為毫秒。
• 4416K->1973K(15872K)表示，GC前，堆記憶體占有4416K，GC後，占有1973K，總大小為15872K
• Full GC表示，記憶體空間全部進行GC
• Metaspace代表元空間

2. 并行垃圾收集器（ParNew）

• 并行垃圾收集器在串行垃圾收集器的基礎之上做了改進，将單線程改為了多線程進行垃圾回收，這樣可以縮短垃圾回收的時間。（這裡是指，并行能力較強的機器）
• 當然了，并行垃圾收集器在收集的過程中也會暫停應用程式，這個和串行垃圾回收器是一樣的，隻是并行執行，速度更快些，暫停的時間更短一些。

• 是service模式下預設的新生代垃圾回收期，因為隻有他能與CMS配合工作

ParNew垃圾收集器

• ParNew垃圾收集器是工作在

  年輕代

  上的，隻是将串行的垃圾收集器改為了并行。
• 通過 -XX:+UseParNewGC 參數設定年輕代使用ParNew回收器，老年代使用的依然是串行收集器。

測試：

#列印出的資訊

[GC (Allocation Failure) [ParNew: 4416K‐>512K(4928K), 0.0032106 secs]

4416K‐>1988K(15872K), 0.0032697 secs] [Times: user=0.00 sys=0.00,

real=0.00 secs]

• 由以上資訊可以看出，

  ParNew

  : 使用的是ParNew收集器。其他資訊和串行收集器一緻

3. ParallelGC垃圾收集器(一般使用這個)

• 是一個

  新生代和老年代

  的
• ParallelGC收集器工作機制和ParNewGC收集器一樣，隻是在此基礎之上，新增了兩個和系統吞吐量相關的參數，使得其使用起來更加的靈活和高效。
• 主要目的為了達到

  吞吐量

  （CPU執行程式的時間如果99s，執行GC1s，吞吐量則為99%）
• 适用于

  高效率利用CPU的程式

  ，如背景計算的程式

相關參數如下：

• -XX:+UseParallelGC（常用）

  年輕代使用ParallelGC垃圾回收器，老年代使用串行回收器。

• -XX:+UseParallelOldGC（常用）

  年輕代使用ParallelGC垃圾回收器，老年代使用ParallelOldGC垃圾回收器。

• -XX:MaxGCPauseMillis（常用）

  設定最大的垃圾收集時的停頓時間，機關為毫秒

需要注意的時，ParallelGC為了達到設定的停頓時間，可能會調整堆大小或其他的參數，如果堆的大小設定的較小，就會導緻GC工作變得很頻繁，反而可能會影響到性能。該參數使用需

謹慎

。

• -XX:GCTimeRatio

  設定垃圾回收時間占程式運作時間的百分比，公式為1/(1+n)。

  它的值為0~100之間的數字，預設值為99，也就是垃圾回收時間不能超過1%

• -XX:UseAdaptiveSizePolicy

  自适應GC模式，垃圾回收器将自動調整年輕代、老年代等參數，達到吞吐量、堆大小、停頓時間之間的平衡。

  一般用于，手動調整參數比較困難的場景，讓收集器自動進行調整。

-Dfile.encoding=UTF-8

-XX:+UseParallelGC

-XX:+UseParallelOldGC

-XX:MaxGCPauseMillis=100

-XX:+PrintGCDetails

-Xms16m

-Xmx16m

運作結果：

[GC (Allocation Failure) [PSYoungGen: 4096K‐>480K(4608K)] 4096K‐

1840K(15872K), 0.0034307 secs] [Times: user=0.00 sys=0.00, real=0.00

secs]

[Full GC (Ergonomics) [PSYoungGen: 505K‐>0K(4608K)] [ParOldGen: 10332K‐

10751K(11264K)] 10837K‐>10751K(15872K), [Metaspace: 3491K‐

3491K(1056768K)], 0.0793622 secs] [Times: user=0.13 sys=0.00, real=0.08

secs]

• PSYoungGen代表着并行的垃圾收集器

4. CMS垃圾收集器（重點）

• CMS全稱 Concurrent Mark Sweep，是一款

  并發的

  、

  使用标記-清除算法

  的垃圾回收器，該回收器是針對

  老年代垃圾回收的

  ，通過參數-XX:+UseConcMarkSweepGC進行設定。
• 解決了垃圾收集時的STW，在垃圾回收時，程式可以繼續運作
• 目的：

  擷取最短的STW

CMS垃圾回收器的執行過程如下：

• 初始化标記(CMS-initial-mark) ,标記root，

  會導緻stw

  ；
• 并發标記(CMS-concurrent-mark)，與使用者線程同時運作；
• 預清理（CMS-concurrent-preclean），與使用者線程同時運作；
• 重新标記(CMS-remark) ，

  會導緻stw

  ；（在預處理結束後，可能會産生新的垃圾）
• 并發清除(CMS-concurrent-sweep)，與使用者線程同時運作；
• 調整堆大小，設定CMS在清理之後進行記憶體壓縮，目的是清理記憶體中的碎片；
• 并發重置狀态等待下次CMS的觸發(CMS-concurrent-reset)，與使用者線程同時運作

測試

#運作日志

[GC (Allocation Failure) [ParNew: 4926K‐>512K(4928K), 0.0041843 secs]

9424K‐>6736K(15872K), 0.0042168 secs] [Times: user=0.00 sys=0.00,

real=0.00 secs]

#第一步，初始标記

[GC (CMS Initial Mark) [1 CMS‐initial‐mark: 6224K(10944K)] 6824K(15872K),

0.0004209 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

#第二步，并發标記

[CMS‐concurrent‐mark‐start]

[CMS‐concurrent‐mark: 0.002/0.002 secs] [Times: user=0.00 sys=0.00,

real=0.00 secs]

#第三步，預處理

[CMS‐concurrent‐preclean‐start]

[CMS‐concurrent‐preclean: 0.000/0.000 secs] [Times: user=0.00 sys=0.00,

real=0.00 secs]

#第四步，重新标記

[GC (CMS Final Remark) [YG occupancy: 1657 K (4928 K)][Rescan (parallel)

, 0.0005811 secs][weak refs processing, 0.0000136 secs][class unloading,

0.0003671 secs][scrub symbol table, 0.0006813 secs][scrub string table,

0.0001216 secs][1 CMS‐remark: 6224K(10944K)] 7881K(15872K), 0.0018324

secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

#第五步，并發清理

[CMS‐concurrent‐sweep‐start]

[CMS‐concurrent‐sweep: 0.004/0.004 secs] [Times: user=0.00 sys=0.00,

real=0.00 secs]

#第六步，重置

[CMS‐concurrent‐reset‐start]

[CMS‐concurrent‐reset: 0.000/0.000 secs] [Times: user=0.00 sys=0.00,

real=0.00 secs]

• 由以上日志資訊，可以看出CMS執行的過程。

缺點：

• 特别依賴CPU資源

  ，如果CPU資源緊張，則會導緻GC時間變長，影響吞吐量

• 無法清除浮動垃圾

  。在标記完成後，可能又出現了垃圾，導緻會觸發第二次的Full GC

• 預設是基于标記-清除算法

  ，會造成碎片化；如果使用标記-整理，會使STW時間變長

5. G1垃圾收集器（重點）

• G1垃圾收集器是在jdk1.7中正式使用的全新的垃圾收集器，oracle官方計劃在jdk9中将G1變成預設的垃圾收集器，以替代CMS
• G1的設計原則就是簡化JVM性能調優，開發人員隻需要簡單的三步即可完成調優：

1. 第一步，開啟G1垃圾收集器
2. 第二步，設定堆的最大記憶體
3. 第三步，設定最大的停頓時間

特點

• 并行與并發。利用CPU多核的來縮短STW的時間
• 分代收集。對不同代的對象采用不同的垃圾回收政策。
• 空間整合。綜合了複制和标記-整理算法，解決了碎片化。
• 可預測的停頓。可以讓使用者設定在一個時間段内STW的時間
• G1中提供了三種模式垃圾回收模式，Young GC、Mixed GC 和 Full GC，在不同的條件下被觸發。

原理

• 加入了Remembered Set

  ，當不同的代發生了引用時，會記錄該引用資訊。保證了即使不掃描全部的堆也不會有遺漏
• 會對每個Region計算一個回收價值，價值越大，越先被回收
• G1垃圾收集器相對比其他收集器而言，最大的差別在于它取消了年輕代、老年代的實體劃分，取而代之的是将堆劃分為若幹個區域（Region），這些區域中包含了有邏輯上的年輕代、老年代區域。
• 這樣做的好處就是，我們再也不用單獨的空間對每個代進行設定了，不用擔心每個代記憶體是否足夠。

  

  

• 在G1劃分的區域中，年輕代的垃圾收集依然采用

  暫停所有應用線程的方式，将存活對象拷貝到老年代或者Survivor空間

  ，G1收集器通過将對象從一個區域複制到另外一個區域，完成了清理工作。(複制算法)
• 這就意味着，在正常的處理過程中，G1完成了堆的壓縮（至少是部分堆的壓縮），這樣也就不會有cms記憶體碎片問題的存在了。
• 在G1中，有一種特殊的區域，叫Humongous區域。
• 如果一個對象占用的空間超過了分區容量50%以上，G1收集器就認為這是一個巨型對象。
• 這些巨型對象，預設直接會被配置設定在老年代，但是如果它是一個短期存在的巨型對象，就會對垃圾收集器造成負面影響。
• 為了解決這個問題，G1劃分了一個Humongous區，它用來專門存放巨型對象。如果
• 一個H區裝不下一個巨型對象，那麼G1會尋找連續的H分區來存儲。為了能找到連續的H區，有時候不得不啟動Full GC。

步驟：

• 初始化标記（STW）
• 并發标記
• 最終标記（可能STW）
• 篩選回收

a. Young GC

• Young GC主要是對

  Eden區

  進行GC，它在Eden空間耗盡時會被觸發。
• Eden空間的資料移動到Survivor空間中，如果Survivor空間不夠，Eden空間的部分資料會直接晉升到年老代空間。
• Survivor區的資料移動到新的Survivor區中，也有部分資料晉升到老年代空間中。
• 最終Eden空間的資料為空，GC停止工作，應用線程繼續執行

Remembered Set（已記憶集合）

• 在GC年輕代的對象時，我們如何找到年輕代中對象的根對象呢？

  根對象可能是在年輕代中，也可以在老年代中，那麼老年代中的所有對象都是根麼？

• 如果全量掃描老年代，那麼這樣掃描下來會耗費大量的時間。

  于是，G1引進了

  RSet

  的概念。它的全稱是Remembered Set，其作用是跟蹤指向某個堆内的對象引用。

• 每個Region初始化時，會初始化一個RSet，該集合用來記錄并跟蹤其它Region指向該Region中對象的引用，每個Region預設按照512Kb劃分成多個Card，是以RSet需要記錄的東西應該是 xx Region的 xx Card。

b. Mixed GC

• 當越來越多的對象晉升到老年代old region時，為了避免堆記憶體被耗盡，虛拟機會觸發一個混合的垃圾收集器，即Mixed GC，該算法并不是一個Old GC，除了回收整個YoungRegion，還會回收一部分的Old Region，這裡需要注意：

  是一部分老年代

  ，而不是全部老年代，可以選擇哪些old region進行收集，進而可以對垃圾回收的耗時時間進行控制。
• 也要注意的是Mixed GC 并不是 Full GC。
• MixedGC什麼時候觸發？ 由參數 -XX:InitiatingHeapOccupancyPercent=n 決定。預設：45%，該參數的意思是：當老年代大小占整個堆大小百分比達到該閥值時觸發。

它的GC步驟分2步：

1. 全局并發标記（global concurrent marking）
2. 拷貝存活對象（evacuation）

全局并發标記,執行過程分為五個步驟：

• 初始标記（initial mark，STW）

  标記從根節點直接可達的對象，這個階段會執行一次

  年輕代GC

  ，會産生全局停頓

• 根區域掃描（root region scan）

  G1 GC 在初始标記的存活區掃描對老年代的引用，并标記被引用的對象。

  該階段與應用程式（

  非 STW

  ）同時運作，并且隻有完成該階段後，才能開始下一次 STW 年輕代垃圾回收。

• 并發标記（Concurrent Marking）

  G1 GC 在整個堆中查找可通路的（存活的）對象（

  非 STW

  ）。該階段與應用程式同時運作，可以被 STW 年輕代垃圾回收中斷。

• 重新标記（Remark，STW）

  該階段是 STW 回收，因為程式在運作，針對上一次的标記進行修正。

• 清除垃圾（Cleanup，STW）清點和重置标記狀态，該階段會STW，這個階段并不會實際上去做垃圾的收集，等待

  evacuation階段來回收

  。

拷貝存活對象

• Evacuation階段是

  全暫停的

  。該階段把一部分Region裡的活對象拷貝到另一部分Region中，進而實作垃圾的回收清理。

G1收集器相關參數

• -XX:+UseG1GC

  使用 G1 垃圾收集器

• -XX:MaxGCPauseMillis

  設定期望達到的最大GC停頓時間名額（JVM會盡力實作，但不保證達到），預設值是 200 毫秒。

• -XX:G1HeapRegionSize=n

  設定的 G1 區域的大小。值是 2 的幂，範圍是 1 MB 到 32 MB 之間。目标是根據最小的 Java 堆大小劃分出約 2048 個區域。

  預設是堆記憶體的1/2000。(

  每一個Region的大小

  )

• -XX:ParallelGCThreads=n

  設定 STW 工作線程數的值。将 n 的值設定為邏輯處理器的數量。n 的值與邏輯處理器的數量相同，最多為 8。

• -XX:ConcGCThreads=n

  設定并行标記的線程數。将 n 設定為并行垃圾回收線程數 (ParallelGCThreads)的 1/4 左右。

• -XX:InitiatingHeapOccupancyPercent=n

  設定觸發标記周期的 Java 堆占用率門檻值。預設占用率是整個 Java 堆的 45%。

測試

#日志

[GC pause (G1 Evacuation Pause) (young), 0.0044882 secs]

[Parallel Time: 3.7 ms, GC Workers: 3]

[GC Worker Start (ms): Min: 14763.7, Avg: 14763.8, Max: 14763.8,

Diff: 0.1]

#掃描根節點

[Ext Root Scanning (ms): Min: 0.2, Avg: 0.3, Max: 0.3, Diff: 0.1,

Sum: 0.8]

#更新RS區域所消耗的時間

[Update RS (ms): Min: 1.8, Avg: 1.9, Max: 1.9, Diff: 0.2, Sum: 5.6]

[Processed Buffers: Min: 1, Avg: 1.7, Max: 3, Diff: 2, Sum: 5]

[Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]

[Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0,

Sum: 0.0]

#對象拷貝

[Object Copy (ms): Min: 1.1, Avg: 1.2, Max: 1.3, Diff: 0.2, Sum:

3.6]

[Termination (ms): Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.2, Sum:

0.2]

[Termination Attempts: Min: 1, Avg: 1.0, Max: 1, Diff: 0, Sum:

3]

[GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0,

Sum: 0.0]

[GC Worker Total (ms): Min: 3.4, Avg: 3.4, Max: 3.5, Diff: 0.1,

Sum: 10.3]

[GC Worker End (ms): Min: 14767.2, Avg: 14767.2, Max: 14767.3,

Diff: 0.1]

[Code Root Fixup: 0.0 ms]

[Code Root Purge: 0.0 ms]

[Clear CT: 0.0 ms] #清空CardTable

[Other: 0.7 ms]

[Choose CSet: 0.0 ms] #選取CSet

[Ref Proc: 0.5 ms] #弱引用、軟引用的處理耗時

[Ref Enq: 0.0 ms] #弱引用、軟引用的入隊耗時

[Redirty Cards: 0.0 ms]

[Humongous Register: 0.0 ms] #大對象區域注冊耗時

[Humongous Reclaim: 0.0 ms] #大對象區域回收耗時

[Free CSet: 0.0 ms]

[Eden: 7168.0K(7168.0K)‐>0.0B(13.0M) Survivors: 2048.0K‐>2048.0K Heap:

55.5M(192.0M)‐>48.5M(192.0M)] #年輕代的大小統計

[Times: user=0.00 sys=0.00, real=0.00 secs]

c. 對于G1垃圾收集器優化建議

年輕代大小

• 避免使用 -Xmn 選項或 -XX:NewRatio 等其他相關選項顯式設定年輕代大小。
• 固定年輕代的大小會覆寫暫停時間目标。
• 因為沒有年輕代的概念，而變成了區域的概念

暫停時間目标不要太過嚴苛

• G1 GC 的吞吐量目标是 90% 的應用程式時間和 10%的垃圾回收時間。
• 評估 G1 GC 的吞吐量時，暫停時間目标不要太嚴苛。目标太過嚴苛表示您願意承受更多的垃圾回收開銷，而這會直接影響到吞吐量

可視化GC日志分析工具

• 前面通過-XX:+PrintGCDetails可以對GC日志進行列印，我們就可以在控制台檢視，這樣雖然可以檢視GC的資訊，但是并不直覺，可以借助于第三方的GC日志分析工具進行檢視。
• 在日志列印輸出涉及到的參數如下

  ‐XX:+PrintGC 輸出GC日志

  ‐XX:+PrintGCDetails 輸出GC的詳細日志

  ‐XX:+PrintGCTimeStamps 輸出GC的時間戳（以基準時間的形式）

  ‐XX:+PrintGCDateStamps 輸出GC的時間戳（以日期的形式，如 2013‐05‐

  04T21:53:59.234+0800）

  ‐XX:+PrintHeapAtGC 在進行GC的前後列印出堆的資訊

  ‐Xloggc:…/logs/gc.log 日志檔案的輸出路徑

測試：

-Dfile.encoding=UTF-8

-XX:+UseG1GC

-XX:MaxGCPauseMillis=100

-Xmx256m

-XX:+PrintGCDetails

-XX:+PrintGCTimeStamps

-XX:+PrintGCDateStamps

-XX:+PrintHeapAtGC

-Xloggc:D://gc.log

GC Easy 可視化工具

GC Easy是一款線上的可視化工具，易用、功能強大，網站：http://gceasy.io/

上傳後，點選“Analyze”按鈕，即可檢視報告上傳後，點選“Analyze”按鈕，即可檢視報告