G1收集器的收集原理

本文轉載自查看原文 2019-01-07 00:43 4214 Java

G1收集器的收集原理

來源 http://blog.jobbole.com/109170/

JVM 8 內存模型

原文：https://blog.csdn.net/bruce128/article/details/79357870

這里介紹的是JDK1.8 JVM運行時內存數據區域划分。1.8同1.7比，最大的差別就是：元數據區取代了永久代。元空間的本質和永久代類似，都是對JVM規范中方法區的實現。不過元空間與永久代之間最大的區別在於：元數據空間並不在虛擬機中，而是使用本地內存。

二、各區域介紹

1. 程序計數器
PC 寄存器，也叫程序計數器。JVM支持多個線程同時運行，每個線程都有自己的程序計數器。倘若當前執行的是 JVM 的方法，則該寄存器中保存當前執行指令的地址；倘若執行的是native 方法，則PC寄存器中為空(undefined)。

當前線程所執行的字節碼的行號指示器;
當前線程私有;
不會出現OutOfMemoryError情況

2. Java虛擬機棧

虛擬機棧：每個線程有一個私有的棧，隨着線程的創建而創建，其生命周期與線程同進同退。棧里面存着的是一種叫“棧幀”的東西，每個Java方法在被調用的時候都會創建一個棧幀，一旦完成調用，則出棧。所有的的棧幀都出棧后，線程也就完成了使命。棧幀中存放了局部變量表（基本數據類型和對象引用）、操作數棧、動態鏈接(指向當前方法所屬的類的運行時常量池的引用等)、方法出口(方法返回地址)、和一些額外的附加信息。棧的大小可以固定也可以動態擴展。當棧調用深度大於JVM所允許的范圍，會拋出StackOverflowError的錯誤，不過這個深度范圍不是一個恆定的值。

線程私有，生命周期與線程相同;
java方法執行的內存模型，每個方法執行的同時都會創建一個棧幀，存儲局部變量表(基本類型、對象引用)、操作數棧、動態鏈接、方法出口等信息;
StackOverflowError異常：當線程請求的棧深度大於虛擬機所允許的深度;
OutOfMemoryError異常：如果棧的擴展時無法申請到足夠的內存。

3. 本地方法棧
本地方法棧與Java棧的作用和原理非常相似。區別只不過是Java棧是為執行Java方法服務的，而本地方法棧則是為執行本地方法（Native Method）服務的。在JVM規范中，並沒有對本地方發展的具體實現方法以及數據結構作強制規定，虛擬機可以自由實現它。在HotSopt虛擬機中直接就把本地方法棧和Java棧合二為一。

4. 堆

堆是JVM內存占用最大，管理最復雜的一個區域。其唯一的用途就是存放對象實例：所有的對象實例及數組都在堆上進行分配。1.7后，字符串常量池從永久代中剝離出來，存放在堆中。堆有自己進一步的內存分塊划分，按照GC分代收集角度的划分請參見上圖。

4.1 堆空間內存分配（默認情況下）

老年代：三分之二的堆空間
年輕代：三分之一的堆空間
- 　　eden區： 8/10 的年輕代空間
- 　　survivor0 : 1/10 的年輕代空間
- 　　survivor1 : 1/10 的年輕代空間

命令行上執行如下命令，查看所有默認的jvm參數

java -XX:+PrintFlagsFinal -version

輸出
輸出有大幾百行，這里只取其中的兩個有關聯的參數

[Global flags]
    uintx InitialSurvivorRatio                      = 8                                   {product}
    uintx NewRatio                                  = 2                                   {product}
    ... ...
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)

參數解釋
參數作用
-XX:InitialSurvivorRatio 新生代Eden/Survivor空間的初始比例
-XX:Newratio Old區和 Yong區的內存比例
一道推算題

默認參數下，如果僅給出eden區40M，求堆空間總大小

根據比例可以推算出，兩個survivor區各5M，年輕代50M。老年代是年輕代的兩倍，即100M。那么堆總大小就是150M。

4.2 字符串常量池
JDK1.7 就開始“去永久代”的工作了。 1.7把字符串常量池從永久代中剝離出來，存放在堆空間中。

a. jvm參數配置

-XX:MaxPermSize=10m
-XX:PermSize=10m
-Xms100m
-Xmx100m
-XX:-UseGCOverheadLimit

b. 測試代碼

public class StringOomMock {

    public static void main(String[] args) {
        try {
            List<String> list = new ArrayList<String>();
            for (int i = 0; ; i++) {
                System.out.println(i);
                list.add(String.valueOf("String" + i++).intern());
            }
        } catch (java.lang.Exception e) {
            e.printStackTrace();
        }
    }
}

c. jdk1.6 下的運行結果
jdk1.6 環境下是永久代OOM

153658
153660
Exception in thread "main" java.lang.OutOfMemoryError: PermGen space
    at java.lang.String.intern(Native Method)
    at com.jd.im.StringOomMock.main(StringOomMock.java:17)

d. jdk1.7 下的運行結果
jdk1.7 下是堆OOM，並且伴隨着頻繁的FullGC， CPU一直高位運行

2252792
2252794
2252796
2252798
*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message can't create name string at ../../../src/share/instrument/JPLISAgent.c line: 807
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at java.nio.CharBuffer.wrap(CharBuffer.java:369)
    at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:265)
    at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:125)
    at java.io.OutputStreamWriter.write(OutputStreamWriter.java:207)
    at java.io.BufferedWriter.flushBuffer(BufferedWriter.java:129)
    at java.io.PrintStream.write(PrintStream.java:526)
    at java.io.PrintStream.print(PrintStream.java:597)
    at java.io.PrintStream.println(PrintStream.java:736)
    at com.jd.im.StringOomMock.main(StringOomMock.java:16)

e. jdk1.8 下的運行結果
jdk1.8的運行結果同1.7的一樣，都是堆空間OOM。

2236898
2236900
2236902
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at java.lang.Integer.toString(Integer.java:403)
    at java.lang.String.valueOf(String.java:3099)
    at java.io.PrintStream.print(PrintStream.java:597)
    at java.io.PrintStream.println(PrintStream.java:736)
    at com.jd.im.StringOomMock.main(StringOomMock.java:16)

5. 元數據區
元數據區取代了1.7版本及以前的永久代。元數據區和永久代本質上都是方法區的實現。方法區存放虛擬機加載的類信息、常量、靜態變量、即時編譯器編譯后的代碼等數據。虛擬機規范是把這個區域(方法區)描述為堆的一個邏輯部分的，但實際它應該是要和堆區分開的。一般情況下為了與堆進行區分，通常又叫“非堆”。

在HotSpot中，方法區≈永久代。不過1.7版本之后，我們使用的HotSpot就沒有永久代這個概念了，而是在本地內存中使用元空間取代了方法區。在1.7版本之前，“PermGen space”(永久代空間) 其實指的就是方法區。不過方法區和“PermGen space”又有着本質的區別。前者是 JVM 的規范，而后者則是 JVM 規范的一種實現，並且只有 HotSpot 才有 “PermGen space”，而對於其他類型的虛擬機，如 JRockit（Oracle）、J9（IBM）並沒有“PermGen space”。由於方法區主要存儲類的相關信息，所以對於動態生成類的情況比較容易出現永久代的內存溢出。最典型的場景就是，在 jsp 頁面比較多的情況，容易出現永久代內存溢出。我們可以通過動態生成類來模擬這個 "java.lang.OutOfMemoryError: PermGen space " 內存溢出的異常。

JDK 8 中永久代向元空間的轉換的幾點原因

1、字符串存在永久代中，容易出現性能問題和內存溢出。
2、類及方法的信息等比較難確定其大小，因此對於永久代的大小指定比較困難，太小容易出現永久代溢出，太大則容易導致老年代溢出。
3、永久代會為 GC 帶來不必要的復雜度，並且回收效率偏低。
4、Oracle 可能會將HotSpot 與 JRockit 合二為一。

其實，移除永久代的工作從JDK1.7就開始了。JDK1.7中，存儲在永久代的部分數據就已經轉移到了Java Heap或者是 Native Heap。但永久代仍存在於JDK1.7中，並沒完全移除，譬如符號引用(Symbols)轉移到了native heap；字面量(interned strings)轉移到了java heap；類的靜態變量(class statics)轉移到了java heap。我們可以通過一段程序來比較 JDK 1.6 與 JDK 1.7及 JDK 1.8 的區別。

元數據區OOM測試：

a. jvm參數配置

-XX:MetaspaceSize=8m 
-XX:MaxMetaspaceSize=50m

b. 測試代碼
借助cglib框架生成新類。

public class MetaSpaceOomMock {

    public static void main(String[] args) {
        ClassLoadingMXBean loadingBean = ManagementFactory.getClassLoadingMXBean();
        while (true) {
            Enhancer enhancer = new Enhancer();
            enhancer.setSuperclass(MetaSpaceOomMock.class);
            enhancer.setCallbackTypes(new Class[]{Dispatcher.class, MethodInterceptor.class});
            enhancer.setCallbackFilter(new CallbackFilter() {
                @Override
                public int accept(Method method) {
                    return 1;
                }

                @Override
                public boolean equals(Object obj) {
                    return super.equals(obj);
                }
            });

            Class clazz = enhancer.createClass();
            System.out.println(clazz.getName());
            //顯示數量信息（共加載過的類型數目，當前還有效的類型數目，已經被卸載的類型數目）
            System.out.println("total: " + loadingBean.getTotalLoadedClassCount());
            System.out.println("active: " + loadingBean.getLoadedClassCount());
            System.out.println("unloaded: " + loadingBean.getUnloadedClassCount());
        }
    }
}

c. 運行輸出：

jvm.MetaSpaceOomMock$$EnhancerByCGLIB$$567f7ec0
total: 6265
active: 6265
unloaded: 0
jvm.MetaSpaceOomMock$$EnhancerByCGLIB$$3501581b
total: 6266
active: 6266
unloaded: 0
Exception in thread "main" net.sf.cglib.core.CodeGenerationException: java.lang.reflect.InvocationTargetException-->null
    at net.sf.cglib.core.AbstractClassGenerator.generate(AbstractClassGenerator.java:345)
    at net.sf.cglib.proxy.Enhancer.generate(Enhancer.java:492)
    at net.sf.cglib.core.AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:93)
    at net.sf.cglib.core.AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:91)
    at net.sf.cglib.core.internal.LoadingCache$2.call(LoadingCache.java:54)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at net.sf.cglib.core.internal.LoadingCache.createEntry(LoadingCache.java:61)
    at net.sf.cglib.core.internal.LoadingCache.get(LoadingCache.java:34)
    at net.sf.cglib.core.AbstractClassGenerator$ClassLoaderData.get(AbstractClassGenerator.java:116)
    at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:291)
    at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:480)
    at net.sf.cglib.proxy.Enhancer.createClass(Enhancer.java:337)
    at jvm.MetaSpaceOomMock.main(MetaSpaceOomMock.java:38)
Caused by: java.lang.reflect.InvocationTargetException
    at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at net.sf.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:413)
    at net.sf.cglib.core.AbstractClassGenerator.generate(AbstractClassGenerator.java:336)
    ... 12 more
Caused by: java.lang.OutOfMemoryError: Metaspace
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
    ... 17 more

如果是1.7的jdk，那么報OOM的將是PermGen區域。

6. 直接內存

直接內存並不是虛擬機運行時數據區的一部分，也不是Java虛擬機規范中定義的內存區域。但是這部分內存也被頻繁地使用，而且也可能導致內存溢出問題。JDK1.4中新增加了NIO，引入了一種基於通道與緩沖區的I/O方式，它可以使用Native函數庫直接分配堆外內存，然后通過一個存儲在Java堆中的DirectByteBuffer對象作為這塊內存的引用進行操作。這樣能在一些場景中顯著提高性能，因為避免了在Java堆和Native堆中來回復制數據。顯然，本機直接內存的分配不會受到Java堆大小的限制，但是，既然是內存，肯定還是會受到本機總內存（包括RAM、SWAP區）大小以及處理器尋址空間的限制。

NIO可以使用Native函數庫直接分配堆外內存，堆中的DirectByteBuffer對象作為這塊內存的引用進行操作;
大小不受Java堆大小的限制，受本機(服務器)內存限制;
OutOfMemoryError異常：系統內存不足時。

-----------------------------------------------------------------

本文首先簡單介紹了垃圾收集的常見方式，然后再分析了G1收集器的收集原理，相比其他垃圾收集器的優勢，最后給出了一些調優實踐。

一，什么是垃圾回收

首先，在了解G1之前，我們需要清楚的知道，垃圾回收是什么？簡單的說垃圾回收就是回收內存中不再使用的對象。

垃圾回收的基本步驟

回收的步驟有2步：

查找內存中不再使用的對象
釋放這些對象占用的內存

1,查找內存中不再使用的對象

那么問題來了，如何判斷哪些對象不再被使用呢？我們也有2個方法：

引用計數法

引用計數法就是如果一個對象沒有被任何引用指向，則可視之為垃圾。這種方法的缺點就是不能檢測到環的存在。

2.根搜索算法

根搜索算法的基本思路就是通過一系列名為”GC Roots”的對象作為起始點，從這些節點開始向下搜索，搜索所走過的路徑稱為引用鏈(Reference Chain)，當一個對象到GC Roots沒有任何引用鏈相連時，則證明此對象是不可用的。

現在我們已經知道如何找出垃圾對象了，如何把這些對象清理掉呢？

2. 釋放這些對象占用的內存

常見的方式有復制或者直接清理，但是直接清理會存在內存碎片，於是就會產生了清理再壓縮的方式。

總得來說就產生了三種類型的回收算法。

1.標記-復制

它將可用內存容量划分為大小相等的兩塊，每次只使用其中的一塊。當這一塊用完之后，就將還存活的對象復制到另外一塊上面，然后在把已使用過的內存空間一次理掉。它的優點是實現簡單，效率高，不會存在內存碎片。缺點就是需要2倍的內存來管理。

2.標記-清理

標記清除算法分為“標記”和“清除”兩個階段：首先標記出需要回收的對象，標記完成之后統一清除對象。它的優點是效率高，缺點是容易產生內存碎片。

3.標記-整理

標記操作和“標記-清理”算法一致，后續操作不只是直接清理對象，而是在清理無用對象完成后讓所有存活的對象都向一端移動，並更新引用其對象的指針。因為要移動對象，所以它的效率要比“標記-清理”效率低，但是不會產生內存碎片。

基於分代的假設

由於對象的存活時間有長有短，所以對於存活時間長的對象，減少被gc的次數可以避免不必要的開銷。這樣我們就把內存分成新生代和老年代，新生代存放剛創建的和存活時間比較短的對象，老年代存放存活時間比較長的對象。這樣每次僅僅清理年輕代，老年代僅在必要時時再做清理可以極大的提高GC效率，節省GC時間。

java垃圾收集器的歷史

第一階段，Serial（串行）收集器

在jdk1.3.1之前，java虛擬機僅僅能使用Serial收集器。 Serial收集器是一個單線程的收集器，但它的“單線程”的意義並不僅僅是說明它只會使用一個CPU或一條收集線程去完成垃圾收集工作，更重要的是在它進行垃圾收集時，必須暫停其他所有的工作線程，直到它收集結束。

PS：開啟Serial收集器的方式

-XX:+UseSerialGC

第二階段，Parallel（並行）收集器

Parallel收集器也稱吞吐量收集器，相比Serial收集器，Parallel最主要的優勢在於使用多線程去完成垃圾清理工作，這樣可以充分利用多核的特性，大幅降低gc時間。

PS:開啟Parallel收集器的方式

-XX:+UseParallelGC -XX:+UseParallelOldGC

第三階段，CMS（並發）收集器

CMS收集器在Minor GC時會暫停所有的應用線程，並以多線程的方式進行垃圾回收。在Full GC時不再暫停應用線程，而是使用若干個后台線程定期的對老年代空間進行掃描，及時回收其中不再使用的對象。

PS:開啟CMS收集器的方式

-XX:+UseParNewGC -XX:+UseConcMarkSweepGC

第四階段，G1（並發）收集器

G1收集器（或者垃圾優先收集器）的設計初衷是為了盡量縮短處理超大堆（大於4GB）時產生的停頓。相對於CMS的優勢而言是內存碎片的產生率大大降低。

PS:開啟G1收集器的方式

-XX:+UseG1GC

二，了解G1

G1的第一篇paper（附錄1）發表於2004年，在2012年才在jdk1.7u4中可用。oracle官方計划在jdk9中將G1變成默認的垃圾收集器，以替代CMS。為何oracle要極力推薦G1呢，G1有哪些優點？

首先，G1的設計原則就是簡單可行的性能調優

開發人員僅僅需要聲明以下參數即可：

-XX:+UseG1GC -Xmx32g -XX:MaxGCPauseMillis=200

其中-XX:+UseG1GC為開啟G1垃圾收集器，-Xmx32g 設計堆內存的最大內存為32G，-XX:MaxGCPauseMillis=200設置GC的最大暫停時間為200ms。如果我們需要調優，在內存大小一定的情況下，我們只需要修改最大暫停時間即可。

其次，G1將新生代，老年代的物理空間划分取消了。

這樣我們再也不用單獨的空間對每個代進行設置了，不用擔心每個代內存是否足夠。

取而代之的是，G1算法將堆划分為若干個區域（Region），它仍然屬於分代收集器。不過，這些區域的一部分包含新生代，新生代的垃圾收集依然采用暫停所有應用線程的方式，將存活對象拷貝到老年代或者Survivor空間。老年代也分成很多區域，G1收集器通過將對象從一個區域復制到另外一個區域，完成了清理工作。這就意味着，在正常的處理過程中，G1完成了堆的壓縮（至少是部分堆的壓縮），這樣也就不會有cms內存碎片問題的存在了。

在G1中，還有一種特殊的區域，叫Humongous區域。如果一個對象占用的空間超過了分區容量50%以上，G1收集器就認為這是一個巨型對象。這些巨型對象，默認直接會被分配在年老代，但是如果它是一個短期存在的巨型對象，就會對垃圾收集器造成負面影響。為了解決這個問題，G1划分了一個Humongous區，它用來專門存放巨型對象。如果一個H區裝不下一個巨型對象，那么G1會尋找連續的H分區來存儲。為了能找到連續的H區，有時候不得不啟動Full GC。

PS：在java 8中，持久代也移動到了普通的堆內存空間中，改為元空間。

對象分配策略

說起大對象的分配，我們不得不談談對象的分配策略。它分為3個階段：

TLAB(Thread Local Allocation Buffer)線程本地分配緩沖區
Eden區中分配
Humongous區分配

TLAB為線程本地分配緩沖區，它的目的為了使對象盡可能快的分配出來。如果對象在一個共享的空間中分配，我們需要采用一些同步機制來管理這些空間內的空閑空間指針。在Eden空間中，每一個線程都有一個固定的分區用於分配對象，即一個TLAB。分配對象時，線程之間不再需要進行任何的同步。

對TLAB空間中無法分配的對象，JVM會嘗試在Eden空間中進行分配。如果Eden空間無法容納該對象，就只能在老年代中進行分配空間。

最后，G1提供了兩種GC模式，Young GC和Mixed GC，兩種都是Stop The World(STW)的。下面我們將分別介紹一下這2種模式。

三，G1 Young GC

Young GC主要是對Eden區進行GC，它在Eden空間耗盡時會被觸發。在這種情況下，Eden空間的數據移動到Survivor空間中，如果Survivor空間不夠，Eden空間的部分數據會直接晉升到年老代空間。Survivor區的數據移動到新的Survivor區中，也有部分數據晉升到老年代空間中。最終Eden空間的數據為空，GC停止工作，應用線程繼續執行。

這時，我們需要考慮一個問題，如果僅僅GC 新生代對象，我們如何找到所有的根對象呢？老年代的所有對象都是根么？那這樣掃描下來會耗費大量的時間。於是，G1引進了RSet的概念。它的全稱是Remembered Set，作用是跟蹤指向某個heap區內的對象引用。

在CMS中，也有RSet的概念，在老年代中有一塊區域用來記錄指向新生代的引用。這是一種point-out，在進行Young GC時，掃描根時，僅僅需要掃描這一塊區域，而不需要掃描整個老年代。

但在G1中，並沒有使用point-out，這是由於一個分區太小，分區數量太多，如果是用point-out的話，會造成大量的掃描浪費，有些根本不需要GC的分區引用也掃描了。於是G1中使用point-in來解決。point-in的意思是哪些分區引用了當前分區中的對象。這樣，僅僅將這些對象當做根來掃描就避免了無效的掃描。由於新生代有多個，那么我們需要在新生代之間記錄引用嗎？這是不必要的，原因在於每次GC時，所有新生代都會被掃描，所以只需要記錄老年代到新生代之間的引用即可。

需要注意的是，如果引用的對象很多，賦值器需要對每個引用做處理，賦值器開銷會很大，為了解決賦值器開銷這個問題，在G1 中又引入了另外一個概念，卡表（Card Table）。一個Card Table將一個分區在邏輯上划分為固定大小的連續區域，每個區域稱之為卡。卡通常較小，介於128到512字節之間。Card Table通常為字節數組，由Card的索引（即數組下標）來標識每個分區的空間地址。默認情況下，每個卡都未被引用。當一個地址空間被引用時，這個地址空間對應的數組索引的值被標記為”0″，即標記為臟被引用，此外RSet也將這個數組下標記錄下來。一般情況下，這個RSet其實是一個Hash Table，Key是別的Region的起始地址，Value是一個集合，里面的元素是Card Table的Index。

Young GC 階段：

階段1：根掃描
靜態和本地對象被掃描
階段2：更新RS
處理dirty card隊列更新RS
階段3：處理RS
檢測從年輕代指向年老代的對象
階段4：對象拷貝
拷貝存活的對象到survivor/old區域
階段5：處理引用隊列
軟引用，弱引用，虛引用處理

四，G1 Mix GC

Mix GC不僅進行正常的新生代垃圾收集，同時也回收部分后台掃描線程標記的老年代分區。

它的GC步驟分2步：

全局並發標記（global concurrent marking）
拷貝存活對象（evacuation）

在進行Mix GC之前，會先進行global concurrent marking（全局並發標記）。 global concurrent marking的執行過程是怎樣的呢？

在G1 GC中，它主要是為Mixed GC提供標記服務的，並不是一次GC過程的一個必須環節。global concurrent marking的執行過程分為五個步驟：

初始標記（initial mark，STW）
在此階段，G1 GC 對根進行標記。該階段與常規的 (STW) 年輕代垃圾回收密切相關。
根區域掃描（root region scan）
G1 GC 在初始標記的存活區掃描對老年代的引用，並標記被引用的對象。該階段與應用程序（非 STW）同時運行，並且只有完成該階段后，才能開始下一次 STW 年輕代垃圾回收。
並發標記（Concurrent Marking）
G1 GC 在整個堆中查找可訪問的（存活的）對象。該階段與應用程序同時運行，可以被 STW 年輕代垃圾回收中斷
最終標記（Remark，STW）
該階段是 STW 回收，幫助完成標記周期。G1 GC 清空 SATB 緩沖區，跟蹤未被訪問的存活對象，並執行引用處理。
清除垃圾（Cleanup，STW）
在這個最后階段，G1 GC 執行統計和 RSet 凈化的 STW 操作。在統計期間，G1 GC 會識別完全空閑的區域和可供進行混合垃圾回收的區域。清理階段在將空白區域重置並返回到空閑列表時為部分並發。

三色標記算法

提到並發標記，我們不得不了解並發標記的三色標記算法。它是描述追蹤式回收器的一種有用的方法，利用它可以推演回收器的正確性。首先，我們將對象分成三種類型的。

黑色:根對象，或者該對象與它的子對象都被掃描
灰色:對象本身被掃描,但還沒掃描完該對象中的子對象
白色:未被掃描對象，掃描完成所有對象之后，最終為白色的為不可達對象，即垃圾對象

當GC開始掃描對象時，按照如下圖步驟進行對象的掃描：

根對象被置為黑色，子對象被置為灰色。

繼續由灰色遍歷,將已掃描了子對象的對象置為黑色。

遍歷了所有可達的對象后，所有可達的對象都變成了黑色。不可達的對象即為白色，需要被清理。

這看起來很美好，但是如果在標記過程中，應用程序也在運行，那么對象的指針就有可能改變。這樣的話，我們就會遇到一個問題：對象丟失問題

我們看下面一種情況，當垃圾收集器掃描到下面情況時：

這時候應用程序執行了以下操作：

A.c=C
B.c=null

這樣，對象的狀態圖變成如下情形：

這時候垃圾收集器再標記掃描的時候就會下圖成這樣：

很顯然，此時C是白色，被認為是垃圾需要清理掉，顯然這是不合理的。那么我們如何保證應用程序在運行的時候，GC標記的對象不丟失呢？有如下2中可行的方式：

在插入的時候記錄對象
在刪除的時候記錄對象

剛好這對應CMS和G1的2種不同實現方式：

在CMS采用的是增量更新（Incremental update），只要在寫屏障（write barrier）里發現要有一個白對象的引用被賦值到一個黑對象的字段里，那就把這個白對象變成灰色的。即插入的時候記錄下來。

在G1中，使用的是STAB（snapshot-at-the-beginning）的方式，刪除的時候記錄所有的對象，它有3個步驟：

1，在開始標記的時候生成一個快照圖標記存活對象

2，在並發標記的時候所有被改變的對象入隊（在write barrier里把所有舊的引用所指向的對象都變成非白的）

3，可能存在游離的垃圾，將在下次被收集

這樣，G1到現在可以知道哪些老的分區可回收垃圾最多。當全局並發標記完成后，在某個時刻，就開始了Mix GC。這些垃圾回收被稱作“混合式”是因為他們不僅僅進行正常的新生代垃圾收集，同時也回收部分后台掃描線程標記的分區。混合式垃圾收集如下圖：

混合式GC也是采用的復制的清理策略，當GC完成后，會重新釋放空間。

至此，混合式GC告一段落了。下一小節我們講進入調優實踐。

五，調優實踐

MaxGCPauseMillis調優

前面介紹過使用GC的最基本的參數：

-XX:+UseG1GC -Xmx32g -XX:MaxGCPauseMillis=200

前面2個參數都好理解，后面這個MaxGCPauseMillis參數該怎么配置呢？這個參數從字面的意思上看，就是允許的GC最大的暫停時間。G1盡量確保每次GC暫停的時間都在設置的MaxGCPauseMillis范圍內。那G1是如何做到最大暫停時間的呢？這涉及到另一個概念，CSet(collection set)。它的意思是在一次垃圾收集器中被收集的區域集合。

Young GC：選定所有新生代里的region。通過控制新生代的region個數來控制young GC的開銷。
Mixed GC：選定所有新生代里的region，外加根據global concurrent marking統計得出收集收益高的若干老年代region。在用戶指定的開銷目標范圍內盡可能選擇收益高的老年代region。

在理解了這些后，我們再設置最大暫停時間就好辦了。首先，我們能容忍的最大暫停時間是有一個限度的，我們需要在這個限度范圍內設置。但是應該設置的值是多少呢？我們需要在吞吐量跟MaxGCPauseMillis之間做一個平衡。如果MaxGCPauseMillis設置的過小，那么GC就會頻繁，吞吐量就會下降。如果MaxGCPauseMillis設置的過大，應用程序暫停時間就會變長。G1的默認暫停時間是200毫秒，我們可以從這里入手，調整合適的時間。

其他調優參數

-XX:G1HeapRegionSize=n

設置的 G1 區域的大小。值是 2 的冪，范圍是 1 MB 到 32 MB 之間。目標是根據最小的 Java 堆大小划分出約 2048 個區域。

-XX:ParallelGCThreads=n

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

如果邏輯處理器不止八個，則將 n 的值設置為邏輯處理器數的 5/8 左右。這適用於大多數情況，除非是較大的 SPARC 系統，其中 n 的值可以是邏輯處理器數的 5/16 左右。

-XX:ConcGCThreads=n

設置並行標記的線程數。將 n 設置為並行垃圾回收線程數 (ParallelGCThreads) 的 1/4 左右。

-XX:InitiatingHeapOccupancyPercent=45

設置觸發標記周期的 Java 堆占用率閾值。默認占用率是整個 Java 堆的 45%。

避免使用以下參數：

避免使用 -Xmn 選項或 -XX:NewRatio 等其他相關選項顯式設置年輕代大小。固定年輕代的大小會覆蓋暫停時間目標。

觸發Full GC

在某些情況下，G1觸發了Full GC，這時G1會退化使用Serial收集器來完成垃圾的清理工作，它僅僅使用單線程來完成GC工作，GC暫停時間將達到秒級別的。整個應用處於假死狀態，不能處理任何請求，我們的程序當然不希望看到這些。那么發生Full GC的情況有哪些呢？

並發模式失敗

G1啟動標記周期，但在Mix GC之前，老年代就被填滿，這時候G1會放棄標記周期。這種情形下，需要增加堆大小，或者調整周期（例如增加線程數-XX:ConcGCThreads等）。

晉升失敗或者疏散失敗

G1在進行GC的時候沒有足夠的內存供存活對象或晉升對象使用，由此觸發了Full GC。可以在日志中看到(to-space exhausted)或者（to-space overflow）。解決這種問題的方式是：

a,增加 -XX:G1ReservePercent 選項的值（並相應增加總的堆大小），為“目標空間”增加預留內存量。

b,通過減少 -XX:InitiatingHeapOccupancyPercent 提前啟動標記周期。

c,也可以通過增加 -XX:ConcGCThreads 選項的值來增加並行標記線程的數目。

巨型對象分配失敗

當巨型對象找不到合適的空間進行分配時，就會啟動Full GC，來釋放空間。這種情況下，應該避免分配大量的巨型對象，增加內存或者增大-XX:G1HeapRegionSize，使巨型對象不再是巨型對象。

由於篇幅有限，G1還有很多調優實踐，在此就不一一列出了，大家在平常的實踐中可以慢慢探索。最后，期待java 9能正式發布，默認使用G1為垃圾收集器的java性能會不會又提高呢？

附錄：

（1），The original G1 paper: Detlefs, D., Flood, C., Heller, S., and Printezis, T. 2004. Garbage-first garbage collection. In Proceedings of the 4th international Symposium on Memory Management (Vancouver, BC, Canada, October 24 – 25, 2004)

================== End

免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。

猜您在找 G1 收集器垃圾收集器之：G1收集器 G1和CMS垃圾收集器搞懂G1垃圾收集器 G1和CMS收集器的區別 CMS 和 G1 收集器比較 JVM之G1收集器 JVM 經典垃圾收集器 —— CMS 收集器和 G1 收集器 JVM垃圾收集算法與收集器（二）G1收集器、ZGC收集器詳解【JVM】G1垃圾收集器深入分析