Java 9 中的 GC 調優基礎

TheAlchemist發表於2017-09-30

在經過了幾次跳票之後,Java 9終於在原計劃日期的整整一年之後釋出了正式版。Java 9引入了很多新的特性,除了閃瞎眼的Module SystemREPL,最重要的變化我認為是預設GC(Garbage Collector)修改為新一代更復雜、更全面、效能更好的G1(Garbage-First)。JDK的維護者在GC選擇上一直是比較保守的,G1從JDK 1.6時代就開始進入開發者的視野,直到今天正式成為Hotspot的預設GC,也是走了很長的路。

本文將主要講解GC調優需要知道的一些基礎知識,會涉及到一些GC的實現細節,但不會對實現細節做很全面的闡述,如果你看完本文之後,能對GC有一個大致的認識,那本文的寫作目的也就達到了。由於在這次寫作過程中,恰逢Java 9正式版釋出,之前都是依賴Java 8的文件寫的,如果有不正確的地方還望指正。本文將包含以下內容:

  1. GC的作用範圍
  2. GC負責的事情
  3. JVM中的4種GC
  4. G1的一些細節
  5. 使用Java 9正式版對G1進行測試
  6. 一些簡單的GC調優方法

一、GC的作用範圍

要談GC的作用範圍,首先要談JVM的記憶體結構,JVM記憶體中主要有以下幾個區域:堆、方法區(JVM規範中的叫法,Hotspot大致對應的是Metaspace)、棧、本地方法棧、PC等,其中GC主要作用在堆上,如下圖所示:

JVM記憶體結構

其中堆和方法區是所有執行緒共享的,其他則為執行緒獨有,HotSpot JVM使用基於分代的垃圾回收機制,所以在堆上又分為幾個不同的區域(在G1中,各年齡代不再是連續的一整片記憶體,為了描述方便,這裡還使用傳統的表示方法),具體如下圖所示:

JVM堆中的分割槽

二、GC負責的事情

GC的發展是隨著JDK(Standard Edition)的發展一步步發展起來的,垃圾回收(Garbage Collection)可以說是JDK裡最影響效能的行為了。GC做的事情,說白了就是「通過對記憶體進行管理,以保障在記憶體足夠的時候,程式可以正常的使用記憶體」。具體而言,GC通常做的事情有以下3個:

1. 分配物件和物件的年齡管理

通常而言,GC需要管理「在上圖中的年輕代(Young)分配物件,然後通過一系列的年齡管理,將之銷燬或晉升到老年代(Tenured)中去」的過程。這個過程會伴隨著若干次的Minor GC。

對於普通的物件而言,分配記憶體是一件很簡單而且快速的事情。在物件還未建立時,其所佔記憶體大小通過類的後設資料就可以確定,而Eden區域的記憶體可以認為是連續的,所以給物件分配記憶體要做的只是在上圖中Eden區域中把指標移動相應的長度,並將地址返回給物件的引用即可。當然實際的過程比這個複雜,在下文中會提到。

不過,有時候一個物件會直接在老年代中建立,這個點也會在後邊提到。

2. 在老年代中進行標記

老年代的GC演算法可以大致是認為是一個標記-整理(Mark-Compact,其實是混合了標記-清理,標記-複製和標記-整理)演算法,所以老年代的垃圾清理首先要做的就是在老年代對存活的物件(可達性分析,關於不同的可達性可以參考JDK解構 – Java中的引用和動態代理的實現)進行標記,對於尋求大吞吐量的伺服器應用來說,這個過程往往需要是併發的。

標記的過程發生在Major GC被觸發之後,不同的GC對於MajorGC的觸發條件和標記過程的實現也不盡相同。

3. 在老年代中進行壓縮

在上一條的基礎上,將還存活的物件進行壓縮(CMS和G1的行為與此有些不同之處),壓縮的過程就是將存活的物件從老年代的起點進行挨個複製,使得老年代維持在一片連續的記憶體中,消除記憶體碎片,對於記憶體分配速度的提升會有很大的幫助。

三、GC的種類

Hotspot會根據宿主機的硬體特性和作業系統型別,將之分為客戶端型(client-class)或者伺服器型(server-class),如果是伺服器型主機,Java 9之前預設使用Parallel GC,Java 9中預設使用G1。對於伺服器型主機的選擇標準是「CPU核心數大於1,記憶體大於2GB」,所以現在大部分的主機都可以認為是伺服器型主機。

這裡討論的所有GC都是基於分代垃圾回收演算法的。

1. Serail

Serail是最早的一款GC,它只使用一個執行緒來做所有的Minor和Major垃圾回收。它在執行時,其他所有的事情都會暫停。其工作方式十分簡單,在需要GC的安全點,它會停止所有其他執行緒(Stop-The-World),對年輕代進行標記-複製,或對老年代進行標記-整理。

可以使用JVM引數-XX:+UseSerialGC來開啟此GC,當使用此引數時,年輕代和老年代將都是用Serial來做垃圾回收。在年輕代使用標記-複製演算法,將Eden中存活的物件和非空的Suvivor區(From)中存活的物件複製到空的Suvivor區(To)中去,同時將一部分Suvivor中的物件晉升到老年代去。在老年代則使用標記-整理演算法。

看起來Serial古老而簡陋,但在宿主機資源緊張或者JVM堆很小的情況下(比如堆記憶體大小隻有不到100M),Serial反而可以達到更好的效果,因為其他併發或並行GC都是基於多執行緒的,會帶來額外的執行緒切換和執行緒間通訊的開銷。

2. Parallel/Throughput

Parallel在Java 9之前是伺服器型宿主機中JVM的預設GC,其垃圾回收的演算法和Serial基本相同,不同之處在與它使用多執行緒來執行。由於使用了多執行緒,可以享受多核CPU帶來的優勢,可以通過引數-XX:+UseParallelGC -XX:+UseParallelOldGC顯示指定。

3. CMS

CMS和G1都屬於「Mostly Concurrent Mark and Sweep Garbage Collector」,可以使用-XX:+UseConcMarkSweepGC引數開啟。CMS的年輕代垃圾回收使用的是Parallel New來做,其行為和Parallel中的差不多相同,他們的實現上有一些不同的地方,比如Parallel可以自動調節年輕代中各區的大小,用的是廣度優先搜尋等。

老年代使用CMS,CMS的回收和Parallel也基本類似,不同點在與,CMS使用的更復雜的可達性分析步驟,並且不是每次都做壓縮的動作,這樣達到的效果就是,Stop-The-World的時長會降低,JVM執行中斷的時間減少,適合在對延遲敏感的場景下使用。

CMS在Java 9中已經被廢棄,但瞭解CMS的行為對理解G1會有一些幫助,所以這裡還是會簡單的敘述一下。CMS的步驟大致如下:

  1. 第一次標記
    從GC Roots開始,找到它們在老年代中第一個可達的物件,這些物件或者是直接被GC Roots引用,或者通過年輕代中的物件被GC Roots引用。這一步會Stop-The-World。
  2. 併發標記
    在第一次標記的基礎上,進一步進行可達性分析,從而標記存活的物件。這一步叫「併發」標記,是因為做標記的執行緒是和應用的工作執行緒併發執行的,也就是說,這一步不會Stop-The-World。
  3. 第二次標記
    在併發標記的過程中,由於程式仍在執行,會導致在併發標記完成後,有一些物件的可達性會發生變化,所以需要再次對他們進行標記。這一步會Stop-The-World。
  4. 清理
    回收不使用的物件,留作以後使用。

CMS的設計比較複雜,所以也帶來了一些問題,比如浮動垃圾(Floating Garbage,指的是在第一步標記可達,但在第二步執行的同時已經不可達的物件),由於不做老年代壓縮,導致老年代會出現較多的記憶體碎片。

4. G1

由於「引入了併發標記」和「不做老年代壓縮」,CMS可以帶來更好的響應時延表現,但同時也帶來了一些問題。G1本身就是作為CMS的替代品出現的,在它的使用場景裡,堆不再是連續的被分為上文所說的各種代,整個堆會被分為一個個區域(Region),每個區域可以是任何代。如下圖所示:

使用G1的JVM某時刻的堆記憶體

其中有紅色方框的為年輕代(標S的為Survivor區域,其他為Eden),其他藍色底的區域為老年代(標H的為大物件區域,用以儲存大物件)。

四、G1的一些細節

G1與以上3種GC相同,也是基於分代的垃圾回收器。它的垃圾回收步驟可以分為年輕代回收(Young-only phase,類似於Minor GC)和混合垃圾回收階段(Space-reclamation phase)。下圖是Oracle文件中對於此兩個階段的示意圖:

G1設計目標和適用物件

G1的設計目標是讓大型的JVM可以動態的控制GC的行為以滿足使用者配置的效能目標。G1會在平衡吞吐和響應時延的基礎上,儘可能的滿足使用者的需求。它適用的JVM往往有以下特徵:

  1. 堆的大小可能達到數十G(或者更大),同時存活的物件數量也很多。
  2. 物件的分配和年齡增長的行為隨著程式的執行不斷的變化
  3. 堆上很容易形成碎片
  4. 要求較少的Stop-The-World暫停時間,通常小於數百毫秒

對G1的行為進行測試

如果想要看垃圾回收的具體執行過程,可以使用虛擬機器引數-Xlog:gc*=debug或者-Xlog:gc*=info,前一個會列印更多的細節。注意傳統的VM引數-XX:+PrintGCDetails在Java9中已經廢棄,會有Warning資訊。可以使用以下程式碼中的程式去測試:

static int TOTAL_SIZE = 1024 * 5;
static Object[] floatingObjs= new Object[TOTAL_SIZE];
static LinkedList<Object> immortalObjs = new LinkedList<Object>();
//釋放浮動垃圾
synchronized static void renewFloatingObjs() {
    System.err.println("存活物件滿========================================");
    if (floatingSize + 5 >= TOTAL_SIZE) {
        floatingObjs= new Object[TOTAL_SIZE];
        floatingSize = 0;
    }
}
//新增浮動垃圾
synchronized static void addObjToFloating(Object obj) {
    if (floatingSize++ < TOTAL_SIZE) {
        floatingObjs[floatingSize] = obj;
        if (immortalSize++ < TOTAL_SIZE) {
            immortalObjs.add(obj);
        } else {
            immortalObjs.remove(new Random().nextInt(TOTAL_SIZE));
            immortalObjs.add(obj);
        }
    }
}

public static void main(String[] args) {
    for (int i = 0; i < 10; i++) {
        new Thread(() -> {
            while (true) {
                try {
                    Thread.sleep(1);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                Byte[] garbage = new Byte[1024 * (1 + new Random().nextInt(20))];
                if (new Random().nextInt(20) < 2) {
                    if (floatingSize + 5 >= TOTAL_SIZE) {
                        renewFloatingObjs();
                    }
                    addObjToFloating(garbage);
                }
            }
        }).start();
    }
}

在這段程式碼中,模擬了常規程式的使用情況。不斷的生成新的大小不等的物件,這些物件中會有大約10%的機會進入浮動垃圾floatingObjs,浮動垃圾會被定期清除。同時會有一部分的物件進入immortalObjs,這些物件被釋放的機會更少,它們大概率將成為老年代的常住使用者。

從上邊的測試可以得到如下GC日誌1,這是一次完整的年輕代GC,從中可以看到,預設的區域大小為1M,同時將開始一次Full GC,其格式大致為[<虛擬機器執行的時長>][<日誌級別>][<標籤>] GC(<GC的標識>) <其他資訊>

//日誌1
[0.014s][info][gc,heap] Heap region size: 1M
//一次完整的年輕代垃圾回收,伴隨著一次暫停
[12.059s][info ][gc,start             ] GC(18) Pause Young (G1 Evacuation Pause)                            
[12.059s][info ][gc,task              ] GC(18) Using 8 workers of 8 for evacuation                          
[12.078s][info ][gc,phases            ] GC(18)   Pre Evacuate Collection Set: 0.0ms                         
[12.078s][info ][gc,phases            ] GC(18)   Evacuate Collection Set: 18.6ms                            
[12.079s][info ][gc,phases            ] GC(18)   Post Evacuate Collection Set: 0.3ms                            
[12.079s][info ][gc,phases            ] GC(18)   Other: 0.3ms                           
[12.079s][info ][gc,heap              ] GC(18) Eden regions: 342->0(315)                            
[12.079s][info ][gc,heap              ] GC(18) Survivor regions: 38->35(48)                         
[12.079s][info ][gc,heap              ] GC(18) Old regions: 425->463                            
[12.079s][info ][gc,heap              ] GC(18) Humongous regions: 0->0                          
[12.078s][debug][gc,ergo,ihop         ] GC(18) Request concurrent cycle initiation (occupancy higher than threshold) occupancy: 485490688B allocation request: 0B threshold: 472331059B (45.00) source: end of GC
[12.078s][debug][gc,ihop              ] GC(18) Basic information (value update), threshold: 472331059B (45.00), target occupancy: 1049624576B, current occupancy: 521069456B, recent allocation size: 20640B, recent allocation duration: 817.38ms, recent old gen allocation rate: 25251.50B/s, recent marking phase length: 0.00ms
[12.078s][debug][gc,ihop              ] GC(18) Adaptive IHOP information (value update), threshold: 472331059B (47.37), internal target occupancy: 997143347B, occupancy: 521069456B, additional buffer size: 367001600B, predicted old gen allocation rate: 318128.08B/s, predicted marking phase length: 0.00ms, prediction active: false
[12.078s][debug][gc,ergo,refine       ] GC(18) Updated Refinement Zones: green: 15, yellow: 45, red: 75
[12.079s][info ][gc,heap              ] GC(18) Eden regions: 342->0(315)
[12.079s][info ][gc,heap              ] GC(18) Survivor regions: 38->35(48)
[12.079s][info ][gc,heap              ] GC(18) Old regions: 425->463
[12.079s][info ][gc,heap              ] GC(18) Humongous regions: 0->0
[12.079s][info ][gc,metaspace         ] GC(18) Metaspace: 5172K->5172K(1056768K)
[12.079s][debug][gc,heap              ] GC(18) Heap after GC invocations=19 (full 0):       
[12.079s][info ][gc                   ] GC(18) Pause Young (G1 Evacuation Pause) 803M->496M(1001M) 19.391ms                             
[12.079s][info ][gc,cpu               ] GC(18) User=0.05s Sys=0.00s Real=0.02s

年輕代回收(Young-only)

對於純粹的年輕代回收,其演算法很簡單,與Parallel和CMS的年輕代十分類似,這是一個多執行緒並行執行的過程,同樣需要Stop-The-World(對應上邊日誌中的Pause Young),停下來所有的工作執行緒,然後將Eden上存活的物件拷貝到Suvivor區域,這裡會將很多個物件從多個不同的區域拷貝到少數的幾個區域內,所以這一步在G1中叫做疏散(Evacuation),同時把Suvivor上觸及年齡閾值的物件晉升到老年代區域。

老年代回收(concurrent cycle)

G1的老年代回收是在老年代空間觸及一個閾值(Initiating Heap Occupancy Percent)之後,這個回收伴隨著年輕代的回收工作,但與上邊所說的回收有些不同。

  1. 年輕代回收:伴隨著年輕代的回收工作,同時會執行併發標記和一部分清理的工作,這樣可以共用年輕代垃圾回收的Stop-The-World。
    1. 第一次標記:對應一次Pause Initial Mark
      和CMS的步驟類似,首先進行第一次標記。但實現方法上有很大的區別,G1首先對當前堆上的物件情況進行一個虛擬快照(Snapshot-At-The-Beginning),然後根據這個快照對老年代的物件和區域進行標記,並執行之後的垃圾回收。之後像CMS一樣會有併發標記的過程。
      這樣會產生一個問題,在這次回收結束之後,會有些物件在併發標記的過程中,它的可達性已經變化,導致已經不可達的物件仍然沒有被回收。但是這樣能帶來更好的響應時間。
    2. 重新標記:對應一次Pause Remark
      在這個階段,G1首先完成上一步開始的標記工作,之後會對特殊引用的物件進行處理(具體可以參考JDK解構 – Java中的引用和動態代理的實現),還有對Metaspace區域進行垃圾回收。這一步會進行Stop-The-World。
    3. 清理:對應一次Pause Cleanup
      這一步主要做的是收集當前堆中的記憶體區域資訊,對空的區域進行回收,為接下來的空間回收做一些準備工作,清理結束之後,通常會伴隨著一次年輕代回收,如果判斷不需要進行空間回收,則會進入下一個年輕代回收的工作。這一步會進行Stop-The-World。
  2. 混合垃圾回收:對應一次或多次Pause Mixed
    主要做的是對老年代的區域記憶體進行疏散(Evacuation),也包含對年輕代的區域回收工作。同時這一步也會動態地調整IHOP

從對G1的GC日誌的分析,可以看到G1的垃圾回收行為是基於一個可預測的模型:GC會不斷的主動觸發垃圾回收,在這個過程中不斷地進行資訊統計和系統GC引數的設定,然後將上邊這些步驟安排在這些垃圾回收過程中。

大物件的分配

正常情況下,一個物件會在年輕代的Eden中建立,然後通過垃圾回收和年齡管理之後,晉升到老年代。但對於某些比較大的物件,可能會直接分配到老年代去。

對於G1,物件大多數情況都會在Eden上分配,如果JVM判斷一個物件為大物件(其閾值可以通過-XX:G1HeapRegionSize來設定),則會直接分配如老年代的大物件區域中。

對於其他的記憶體區域連續的GC,下面是從StackOverflow上搬運過來的物件在堆上的分配過程:

  1. 使用 thread local allocation buffer (TLAB), 如果空間足夠,則分配成功。
    從名稱便可知,TLAB是執行緒獨佔的,所以執行緒安全,且速度非常快。如果一個TLAB滿了,執行緒會被分配一個新的TLAB。
  2. 如果TLAB 空間不夠這次分配物件,但其中還有很多空間可用,則不使用TLAB,直接在Eden中分配物件。
    直接在Eden上分配物件要去搶佔Eden中的指標操作,其代價較使用TLAB要大一些。
  3. 如果Eden的物件分配失敗,出發Minor GC。
  4. 如果Minor GC完成後還不夠,則直接分配到老年代。

一些簡單的GC調優方法

1. 使用不同的索引物件

引用的型別會直接影響其所引用物件的GC行為,當要做一些記憶體敏感的應用時,可以參考使用合適的引用型別。具體可以參考JDK解構 – Java中的引用和動態代理的實現

2. 使用Parallel

從上文中可知,Java 8預設的GC是Parallel,它也叫Throughput,所以它的目的是儘可能的增加系統的吞吐量。在Parallel裡,可以通過引數調節最大停止時間(-XX:MaxGCPauseMillis,預設無設定)和吞吐量(-XX:GCTimeRatio,預設值是99,即最大使用1%的時間來做垃圾回收)來調優GC的行為。其中設定最大停止時間可能會導致GC調節各年齡代分割槽的尺寸(通過增量來實現)。

3. 使用G1

從Java 9開始G1變成了預設的GC,G1中有一些細節的概念在上文中沒有敘述,這裡先介紹一下:

  1. Remembered Sets(Rsets):對於每個區域,都有一個集合記錄這個區域中所有的引用。
  2. G1 refinement:G1中需要有一系列的執行緒不斷地維護Rsets。
  3. Collection Sets(Csets):在垃圾回收中需要被回收的區域,這些區域中的可達物件(活著的物件)會被疏散。這些區域可能是任何年齡代。
  4. 寫屏障(Write Barriers):對於每一次賦值操作,G1都會有兩個寫屏障,寫之前(Pre-Write)一個,寫之後(Post-Write)一個。Pre-write主要與SATB相關,Post-write主要與Rsets相關
  5. Dirty Card Queue:寫屏障會將寫的記錄放入這個佇列,會有執行緒將這裡的物件不斷的刷入Rsets。
  6. Green/Yellow/Red Zone:三個會影響處理Dirty Card Queue執行緒數的閾值。根據Dirty Card Queue中元素的個數,可以來設定一些GC行為(可以認為是邏輯上將Dirty Card Queue分隔成多個區域)。Green表示超過此閾值則開始新建執行緒來處理這個佇列,Yellow表示超過此閾值,強制啟動這些執行緒,Red表示超過此閾值則會讓寫操作的執行緒自己來執行G1 refinement。

G1提供了豐富的基於不同目的的可調優的引數,列表如下:

引數 描述
-XX:+G1UseAdaptiveConcRefinement, 調節G1 refinement所使用的資源。
-XX:G1ConcRefinementGreenZone=<ergo>, 調節G1 refinement所使用的資源。
-XX:G1ConcRefinementYellowZone=<ergo>, 調節G1 refinement所使用的資源。
-XX:G1ConcRefinementRedZone=<ergo>, 調節G1 refinement所使用的資源。
-XX:G1ConcRefinementThreads=<ergo> 調節G1 refinement所使用的資源。
-XX:G1RSetUpdatingPauseTimePercent=10 調節G1 refinement所需要的時間在整個垃圾回收時間的比例,G1會根據這個時間動態地調節第一行的各個引數。
-XX:+ReduceInitialCardMarks 批量執行物件的生成,以減少初始標記的時間
-XX:-ParallelRefProcEnabled 使用多執行緒處理上文中所說的在重新標記階段對引用的處理
-XX:G1SummarizeRSetStatsPeriod=<n> 設定n次垃圾回收後,列印Rsets的總結性報告。
-XX:GCTimeRatio=<n> 設定GC吞吐量。GC總共應該使用的時間是1 / (1 + n),這個引數會影響不同年齡代尺寸的增長。
-XX:G1HeapRegionSize 設定區域的大小

主要參考文件:

  1. Getting Started with the G1 Garbage Collector
  2. Garbage-First Garbage Collector Tuning
  3. Evaluating and improving remembered sets in the HotSpot G1 garbage collector
  4. G1GC Internals
  5. GC Algorithms: Basics
  6. Java中幾種常量池的區分

相關文章