Java垃圾回收機制（GC策略）

　　核心：1，哪些是垃圾？【怎么確定這個是垃圾】；2，如何回收垃圾？【怎么更好收垃圾】。

　　Java語言相對於C++等語言有一個自動垃圾回收機制，只用管使用【實例化對象】，后續的垃圾回收有專門的后勤人員來處理【garbage collection-GC】；但是C++需要在實例化對象之后，還需手動進行垃圾回收，就和學校的自帶餐盤的食堂一樣，吃完飯還需要自己去洗碗筷，收拾一番。

1，哪些是垃圾？

1.1 垃圾分類【你是什么垃圾！】

 

 

　　什么是垃圾？通俗的講，我們不會再使用到的東西就是垃圾。這里需要注意：有些東西我們可能后續還要使用也可能不會使用，這個就如同曹丞相口中的【雞肋】一般，所以這里的垃圾也是分層次的，對象都是介於垃圾與非垃圾之間的東西。

　　備注：假設1表示非垃圾，0表示垃圾，那么這些實例化對象就是屬於[0,1]之間的類別。

　　⑴強引用（StrongReference）【暫時不是垃圾，未來不確定】

　　　　強引用是使用最普遍的引用。如果一個對象具有強引用，那垃圾回收器絕不會回收它。當內存空間不足，Java虛擬機寧願拋出OutOfMemoryError錯誤，使程序異常終止，也不會靠隨意回收具有強引用的對象來解決內存不足的問題。

 

　　⑵軟引用（SoftReference）【當內存不足，將它當成垃圾回收】

　　　　如果一個對象只具有軟引用，則內存空間足夠，垃圾回收器就不會回收它；如果內存空間不足了，就會回收這些對象的內存。只要垃圾回收器沒有回收它，該對象就可以被程序使用。軟引用可用來實現內存敏感的高速緩存（下文給出示例）。

　　　　軟引用可以和一個引用隊列（ReferenceQueue）聯合使用，如果軟引用所引用的對象被垃圾回收器回收，Java虛擬機就會把這個軟引用加入到與之關聯的引用隊列中。

 

　　⑶弱引用（WeakReference）【垃圾，由JVM中的垃圾回收器發現並回收】

　　　　弱引用與軟引用的區別在於：只具有弱引用的對象擁有更短暫的生命周期。在垃圾回收器線程掃描它所管轄的內存區域的過程中，一旦發現了只具有弱引用的對象，不管當前內存空間足夠與否，都會回收它的內存。不過，由於垃圾回收器是一個優先級很低的線程，因此不一定會很快發現那些只具有弱引用的對象。

　　　　弱引用可以和一個引用隊列（ReferenceQueue）聯合使用，如果弱引用所引用的對象被垃圾回收，Java虛擬機就會把這個弱引用加入到與之關聯的引用隊列中。

 

　　⑷虛引用（PhantomReference）【空指針垃圾？？？】

　　　　“虛引用”顧名思義，就是形同虛設，與其他幾種引用都不同，虛引用並不會決定對象的生命周期。如果一個對象僅持有虛引用，那么它就和沒有任何引用一樣【null】，在任何時候都可能被垃圾回收器回收。

　　　　虛引用主要用來跟蹤對象被垃圾回收器回收的活動。虛引用與軟引用和弱引用的一個區別在於：虛引用必須和引用隊列 （ReferenceQueue）聯合使用。當垃圾回收器准備回收一個對象時，如果發現它還有虛引用，就會在回收對象的內存之前，把這個虛引用加入到與之 關聯的引用隊列中。

　　　　程序可以通過判斷引用隊列中是否已經加入了虛引用，來了解被引用的對象是否將要被垃圾回收。如果程序發現某個虛引用已經被加入到引用隊列，那么就可以在所引用的對象的內存被回收之前采取必要的行動。

①垃圾成因

package _3垃圾的分類;

public class GC1 {//對象失去索引稱為垃圾
    public static void main(String[] args) {
        ObjString objString = new ObjString("hello");
        System.out.println(objString);
        objString = null;
        System.out.println(objString);
    }
}
/*
ObjString: hello
null
 */

②主動調用System.gc()進行垃圾空間處理

package _3垃圾的分類;

public class GC2 {//對象失去索引稱為垃圾，調用GC處理
    public static void main(String[] args) {
        ObjString str = new ObjString("hello");
        ObjString str1 = new ObjString("world");
        System.out.println(str);
        System.out.println(str1);
        str = null;
        str1 = null;
        System.gc();//本質Runtime.getRuntime().gc();
    }
}
/*
ObjString: hello
ObjString: world
2垃圾回收
1垃圾回收
 */

③內存空間不足，JVM自動調用GC處理

package _3垃圾的分類;

public class GC3 {//對象失去索引稱為垃圾，
    public static void main(String[] args) {
        ObjString objString = new ObjString("hello");
        System.out.println(objString);
        objString = null;
        String[] array = new String[1024 * 500];
        for(int i = 0; i < 1024 * 500; i++) {//系統消耗大量內存，JVM需要進行內存回收
            for(int j = 'a'; j <= 'z'; j++) {
                array[i] += (char)j;
            }
        }
    }
}
/*
ObjString: hello
1垃圾回收
 */

④強引用對象，不是垃圾！

package _3垃圾的分類;

public class GC4 {//①強引用，對象有索引存在，不是垃圾
    public static void main(String[] args) {
        ObjString objString = new ObjString("hello");
        System.out.println(objString);
        System.gc();
    }
}
/*
ObjString: hello
 */

⑤軟引用對象，內存不足的時候是垃圾，內存足夠的時候不是垃圾；depend on內存條件

package _3垃圾的分類;

import java.lang.ref.SoftReference;
/*
ObjString objString = new ObjString();
If(JVM.內存不足()) {
    objString = null;//將該對象一並轉換為垃圾
    System.gc();
}
 */
public class GC5 {//②軟引用，當系統內存不足的時候回收
    public static void main(String[] args) {
        SoftReference ref = new SoftReference(new ObjString("這是一個軟引用實例化對象"));
        System.out.println(ref.get());
//        System.gc();
        String[] array = new String[1024 * 500];
        for(int i = 0; i < 1024 * 500; i++) {//系統消耗大量內存，JVM需要進行內存回收
            for(int j = 'a'; j <= 'z'; j++) {
                array[i] += (char)j;
            }
        }
    }
}
/*
ObjString: 這是一個軟引用實例化對象
1垃圾回收
 */

⑥弱引用是垃圾，當JVM垃圾回收的時候進行處理

package _3垃圾的分類;

import java.lang.ref.WeakReference ;
/*
等同於：
ObjString objString = new ObjString();
if(JVM觸發垃圾回收操作){
    objString = null;//強制轉換為垃圾
    System.gc();//進行回收
}
 */
public class GC6 {//③弱引用，當JVM垃圾回收的時候進行處理
    public static void main(String[] args) {
        WeakReference  ref = new WeakReference (new ObjString("這是一個弱引用實例化對象"));
        System.out.println(ref.get());
        System.gc();
    }
}
/*
ObjString: 這是一個弱引用實例化對象
1垃圾回收
 */

⑦假象引用，在實例化后就被置空拋棄！！！ ，就被終止回收

package _3垃圾的分類;

import java.lang.ref.PhantomReference;
import java.lang.ref.ReferenceQueue;
/*
等同於：
ObjString objString = new ObjString();
objString = null;
 */
public class GC7 {//④假象引用，在實例化后就被置空拋棄！！！ ，就被終止回收
    public static void main(String[] args) {
        ReferenceQueue queue = new ReferenceQueue();//假象引用必須和ReferenceQueue聯合使用
        PhantomReference ref = new PhantomReference(new ObjString("這是一個弱引用實例化對象"), queue);
        System.out.println(ref.get());
        System.gc();
    }
}
/*
null
1垃圾回收
 */

1.2 怎么定義垃圾【你是不是垃圾!】

　　前一小節定義了垃圾分類，這一小結我們來看看【你是不是垃圾】。沒有索引不能夠被重新使用的對象！系統無法重新復用這個對象了！

　　這里有兩種方法來確定失去索引的對象，是否是垃圾！①引用計數法；②可達性分析法；

 

 

1.2.1 引用計數法

　　引用計數算法（Reachability Counting）是通過在對象頭中分配一個空間來保存該對象被引用的次數（Reference Count）。如果該對象被其它對象引用，則它的引用計數加1，如果刪除對該對象的引用，那么它的引用計數就減1，當該對象的引用計數為0時，那么該對象就會被回收。

　　String m = new String("jack");

　　先創建一個字符串，這時候"jack"有一個引用，就是 m。

圖1 引用計數原理圖【初始化】

圖2 引用計數原理圖【索引置空】

 

　　但是這樣做也有一個問題出現-交織空引用。首先兩個對象互相引用；之后，兩個索引都置空；但是RC並不等於零，因為他們交織引用了對方。這就造成了本應該是垃圾的對象，無法被判定為垃圾，無法收回！！！

圖3 空索引-交織引用

ReferenceGC.java

package _1引用計數算法;

class ReferenceGC{
    private int counter=0;//對象的索引數
    public Object Root=null;//操作的對象
    public Object instance=null;
    public ReferenceGC(Object object){
        this.Root=object;
    }
    public void add(){//模擬計數器增加
        this.counter++;
    }
    public void sub(){//模擬計數器減少
        this.counter--;
    }
    public int getCounter() {
        return this.counter;
    }
}

testGC.java

package _1引用計數算法;

public class testGC {
    public static void main(String[] args) {
        ReferenceGC a=new ReferenceGC("Obj_A");
        ReferenceGC b=new ReferenceGC("Obj_B");

        String str1=(String) a.Root;//①對象第一次有索引
        String str2=(String) b.Root;
        a.add();
        b.add();
        a.instance=b.Root;//②對象互相引用
        b.instance=a.Root;
        a.add();
        b.add();
        a.Root=null;
        b.Root=null;
        a.sub();
        b.sub();
        System.out.println("a.instance="+a.instance+",b.instance="+b.instance);
        System.out.println("a.getCounter()="+a.getCounter()+",b.getCounter()="+a.getCounter());
    }
}
/*
a.instance=Obj_B,b.instance=Obj_A
a.getCounter()=1,b.getCounter()=1
 */

 

1.2.2 可達性分析法

　　可達性分析算法（Reachability Analysis）的基本思路是，通過一些被稱為垃圾回收根（GC Roots）的對象作為起點，從這些節點開始向下搜索，搜索走過的路徑被稱為引用鏈（Reference Chain)，當一個對象到 GC Roots 沒有任何引用鏈相連時（即從 GC Roots 節點到該節點不可達），則證明該對象是不可用的。

圖4 可達性分析法

　　通過可達性算法，成功解決了引用計數所無法解決的問題-“循環依賴”，只要你無法與 GC Root 建立直接或間接的連接，系統就會判定你為可回收對象。那這樣就引申出了另一個問題，哪些屬於 GC Root。

在 Java 語言中，可作為 GC Root 的對象包括以下4種：

• ①虛擬機棧（棧幀中的本地變量表）中引用的對象
• ②方法區中類靜態屬性引用的對象
• ③方法區中常量引用的對象
• ④本地方法棧中 JNI（即一般說的 Native 方法）引用的對象

 

圖5 Java內存區域

　　1、虛擬機棧（棧幀中的本地變量表）中引用的對象
　　　　此時的 s，即為 GC Root，當s置空時，localParameter 對象也斷掉了與 GC Root 的引用鏈，將被回收。

StackLocalParameter.java

package _2可達性分析算法;

class StackLocalParameter {
    public StackLocalParameter(String name){}
    @Override
    protected void finalize() throws Throwable {
        System.out.println("垃圾回收");
    }

    public static void testGC(){
        StackLocalParameter s = new StackLocalParameter("localParameter");
        s = null;
    }
}

TestGC1.java

package _2可達性分析算法;

public class TestGC1 {
    public static void main(String[] args) {
        StackLocalParameter.testGC();
        System.gc();
    }
}

　　2、方法區中類靜態屬性引用的對象
　　　　s 為 GC Root，s 置為 null，經過 GC 后，s 所指向的 properties 對象由於無法與 GC Root 建立關系被回收。

　　　　而 m 作為類的靜態屬性，也屬於 GC Root，parameter 對象依然與 GC root 建立着連接，所以此時 parameter 對象並不會被回收。

MethodAreaStaicProperties.java【其中parameter並沒有進行垃圾回收】

package _2可達性分析算法;

public class MethodAreaStaicProperties {
    public static MethodAreaStaicProperties m;
    public MethodAreaStaicProperties(String name){}
    @Override
    protected void finalize() throws Throwable {
        System.out.println("垃圾回收");
    }
    public static void testGC(){
        MethodAreaStaicProperties s = new MethodAreaStaicProperties("properties");
        MethodAreaStaicProperties s1 = new MethodAreaStaicProperties("properties");
        s.m = new MethodAreaStaicProperties("parameter");
        s = null;
        s1 = null;
    }
}

TestGC2.java

package _2可達性分析算法;

public class TestGC2 {
    public static void main(String[] args) {
        MethodAreaStaicProperties.testGC();
        System.gc();
    }
}

　　3、方法區中常量引用的對象
　　　　m 即為方法區中的常量引用，也為 GC Root，s 置為 null 后，final 對象也不會因沒有與 GC Root 建立聯系而被回收。

MethodAreaStaicProperties1.java

package _2可達性分析算法;

public class MethodAreaStaicProperties1 {
    public static final MethodAreaStaicProperties1 m = new MethodAreaStaicProperties1("final");//常量索引，無法修改
    private String name;
    public MethodAreaStaicProperties1(String name){
        this.name=name;
    }
    @Override
    protected void finalize() throws Throwable {
        System.out.println("垃圾回收");
    }
    public static void testGC(){
        MethodAreaStaicProperties s = new MethodAreaStaicProperties("staticProperties");
        s = null;
    }
}

TestGC3.java

package _2可達性分析算法;

public class TestGC3 {
    public static void main(String[] args) {
        MethodAreaStaicProperties1.testGC();
        System.gc();
    }
}

　　4、本地方法棧中引用的對象
　　　　任何 native 接口都會使用某種本地方法棧，實現的本地方法接口是使用 C 連接模型的話，那么它的本地方法棧就是 C 棧。當線程調用 Java 方法時，虛擬機會創建一個新的棧幀並壓入 Java 棧。然而當它調用的是本地方法時，虛擬機會保持 Java 棧不變，不再在線程的 Java 棧中壓入新的幀，虛擬機只是簡單地動態連接並直接調用指定的本地方法。

圖6 調用Java方法和本地方法

2，如何回收垃圾？

 　　上文已經確定標定了垃圾，后續要如何清理呢？【高效、快速、節能】

　　在確定了哪些垃圾可以被回收后，垃圾收集器要做的事情就是開始進行垃圾回收，但是這里面涉及到一個問題是：如何高效地進行垃圾回收。由於Java虛擬機規范並沒有對如何實現垃圾收集器做出明確的規定，因此各個廠商的虛擬機可以采用不同的方式來實現垃圾收集器，這里我們討論幾種常見的垃圾收集算法的核心思想：①標記-清除法；②復制算法；③標記整理算法；④內存模型與回收策略

 

 

2.1 標記-清除法

　　標記清除算法（Mark-Sweep）是最基礎的一種垃圾回收算法，它分為2部分，先把內存區域中的這些對象進行標記，哪些屬於可回收標記出來，然后把這些垃圾拎出來清理掉。就像上圖一樣，清理掉的垃圾就變成未使用的內存區域，等待被再次使用。

　　這邏輯再清晰不過了，並且也很好操作，但它存在一個很大的問題，那就是內存碎片。

　　上圖中等方塊的假設是 2M，小一些的是 1M，大一些的是 4M。等我們回收完，內存就會切成了很多段。我們知道開辟內存空間時，需要的是連續的內存區域，這時候我們需要一個 2M的內存區域，其中有2個 1M 是沒法用的。這樣就導致，其實我們本身還有這么多的內存的，但卻用不了。

圖7 標記-清除法

　　優點：簡單快捷；缺點：內存碎片化嚴重

2.2 復制算法

　　復制算法（Copying）是在標記清除算法上演化而來，解決標記清除算法的內存碎片問題。它將可用內存按容量划分為大小相等的兩塊，每次只使用其中的一塊。當這一塊的內存用完了，就將還存活着的對象復制到另外一塊上面，然后再把已使用過的內存空間一次清理掉。保證了內存的連續可用，內存分配時也就不用考慮內存碎片等復雜情況，邏輯清晰，運行高效。

　　上面的圖很清楚，也很明顯的暴露了另一個問題，合着我這140平的大三房，只能當70平米的小兩房來使？代價實在太高。

圖8 復制算法

　　優點：內存碎片化問題得到部分解決；缺點：內存的有效使用率太低。

2.3 標記整理(清除)算法

　　標記整理算法（Mark-Compact）標記過程仍然與標記 --- 清除算法一樣，但后續步驟不是直接對可回收對象進行清理，而是讓所有存活的對象都向一端移動，再清理掉端邊界以外的內存區域。

　　標記整理算法一方面在標記-清除算法上做了升級，解決了內存碎片的問題，也規避了復制算法只能利用一半內存區域的弊端。看起來很美好，但從上圖可以看到，它對內存變動更頻繁，需要整理所有存活對象的引用地址，在效率上比復制算法要差很多。

圖9 標記-整理-清除算法

　　優點：解決內存碎片化問題並且內存利用率大大提高；缺點：內存需要不斷地變動，效率變低。

 2.4 分代收集算法分代收集算法

　　分代收集算法分代收集算法（Generational Collection）-【GC】嚴格來說並不是一種思想或理論，而是融合上述3種基礎的算法思想，而產生的針對不同情況所采用不同算法的一套組合拳。對象存活周期的不同將內存划分為幾塊。一般是把 Java 堆分為新生代和老年代，這樣就可以根據各個年代的特點采用最適當的收集算法。在新生代中，每次垃圾收集時都發現有大批對象死去，只有少量存活，那就選用復制算法，只需要付出少量存活對象的復制成本就可以完成收集。而老年代中因為對象存活率高、沒有額外空間對它進行分配擔保，就必須使用標記-清理或者標記 --- 整理算法來進行回收。so，另一個問題來了，那內存區域到底被分為哪幾塊，每一塊又有什么特別適合什么算法呢？

3 Java內存模型與回收策略

　　Java 堆（Java Heap）是JVM所管理的內存中最大的一塊，堆又是垃圾收集器管理的主要區域，這里我們主要分析一下 Java 堆的結構。

圖10 Java堆結構

　　Java 堆主要分為2個區域-年輕代與老年代，其中年輕代又分 Eden 區和 Survivor 區，其中 Survivor 區又分 From 和 To 2個區。可能這時候大家會有疑問，為什么需要 Survivor 區，為什么Survivor 還要分2個區。不着急，我們從頭到尾，看看對象到底是怎么來的，而它又是怎么沒的。

3.1 Eden 區

　　IBM 公司的專業研究表明，有將近98%的對象是朝生夕死，所以針對這一現狀，大多數情況下，對象會在新生代 Eden 區中進行分配，當 Eden 區沒有足夠空間進行分配時，虛擬機會發起一次 Minor GC【小型回收】，Minor GC 相比 Major GC【大型回收】 更頻繁，回收速度也更快。

通過 Minor GC 之后，Eden 會被清空，Eden 區中絕大部分對象會被回收，而那些無需回收的存活對象，將會進到 Survivor 的 From 區（若 From 區不夠，則直接進入 Old 區）。

3.2 Survivor 區

　　Survivor 區相當於是 Eden 區和 Old 區的一個緩沖，類似於我們交通燈中的黃燈。Survivor 又分為2個區，一個是 From 區，一個是 To 區。每次執行 Minor GC，會將 Eden 區和 From 存活的對象放到 Survivor 的 To 區（如果 To 區不夠，則直接進入 Old 區）。

　　1、為啥需要？

　　不就是新生代到老年代么，直接 Eden 到 Old 不好了嗎，為啥要這么復雜。想想如果沒有 Survivor 區，Eden 區每進行一次 Minor GC，存活的對象就會被送到老年代，老年代很快就會被填滿。而有很多對象雖然一次 Minor GC 沒有消滅，但其實也並不會蹦躂多久，或許第二次，第三次就需要被清除。這時候移入老年區，很明顯不是一個明智的決定。

　　所以，Survivor 的存在意義就是減少被送到老年代的對象，進而減少 Major GC 的發生。Survivor 的預篩選保證，只有經歷16次 Minor GC 還能在新生代中存活的對象，才會被送到老年代。

　　2、為啥需要倆？

　　設置兩個 Survivor 區最大的好處就是解決內存碎片化。

　　我們先假設一下，Survivor 如果只有一個區域會怎樣。Minor GC 執行后，Eden 區被清空了，存活的對象放到了 Survivor 區，而之前 Survivor 區中的對象，可能也有一些是需要被清除的。問題來了，這時候我們怎么清除它們？在這種場景下，我們只能標記清除，而我們知道標記清除最大的問題就是內存碎片，在新生代這種經常會消亡的區域，采用標記清除必然會讓內存產生嚴重的碎片化。因為 Survivor 有2個區域，所以每次 Minor GC，會將之前 Eden 區和 From 區中的存活對象復制到 To 區域。第二次 Minor GC 時，From 與 To 職責兌換，這時候會將 Eden 區和 To 區中的存活對象再復制到 From 區域，以此反復。

　　這種機制最大的好處就是，整個過程中，永遠有一個 Survivor space 是空的，另一個非空的 Survivor space 是無碎片的。那么，Survivor 為什么不分更多塊呢？比方說分成三個、四個、五個?顯然，如果 Survivor 區再細分下去，每一塊的空間就會比較小，容易導致 Survivor 區滿，兩塊 Survivor 區可能是經過權衡之后的最佳方案。

3.3 Old 區

　　老年代占據着2/3的堆內存空間，只有在 Major GC 的時候才會進行清理，每次 GC 都會觸發“Stop-The-World”。內存越大，STW 的時間也越長，所以內存也不僅僅是越大就越好。由於復制算法在對象存活率較高的老年代會進行很多次的復制操作，效率很低，所以老年代這里采用的是標記 --- 整理算法。

　　除了上述所說，在內存擔保機制下，無法安置的對象會直接進到老年代，以下幾種情況也會進入老年代。

　　1、大對象

　　　　大對象指需要大量連續內存空間的對象，這部分對象不管是不是“朝生夕死”，都會直接進到老年代。這樣做主要是為了避免在 Eden 區及2個 Survivor 區之間發生大量的內存復制。當你的系統有非常多“朝生夕死”的大對象時，得注意了。

　　2、長期存活對象

　　　　虛擬機給每個對象定義了一個對象年齡（Age）計數器。正常情況下對象會不斷的在 Survivor 的 From 區與 To 區之間移動，對象在 Survivor 區中每經歷一次 Minor GC，年齡就增加1歲。當年齡增加到15歲時，這時候就會被轉移到老年代。當然，這里的15，JVM 也支持進行特殊設置。

　　3、動態對象年齡

　　　　虛擬機並不重視要求對象年齡必須到15歲，才會放入老年區，如果 Survivor 空間中相同年齡所有對象大小的綜合大於 Survivor 空間的一般，年齡大於等於該年齡的對象就可以直接進去老年區，無需等你“成年”。

　　　　這其實有點類似於負載均衡，輪詢是負載均衡的一種，保證每台機器都分得同樣的請求。看似很均衡，但每台機的硬件不通，健康狀況不同，我們還可以基於每台機接受的請求數，或每台機的響應時間等，來調整我們的負載均衡算法。

4 Stop-The-World

　　在新生代進行的GC叫做minor GC，在老年代進行的GC都叫major GC，Full GC同時作用於新生代和老年代。在垃圾回收過程中經常涉及到對對象的挪動（比如上文提到的對象在Survivor 0和Survivor 1之間的復制），進而導致需要對對象引用進行更新。為了保證引用更新的正確性，Java將暫停所有其他的線程，這種情況被稱為“Stop-The-World”，導致系統全局停頓。Stop-The-World對系統性能存在影響，因此垃圾回收的一個原則是盡量減少“Stop-The-World”的時間。

 

 

　　不同垃圾收集器的Stop-The-World情況，Serial、Parallel和CMS收集器均存在不同程度的Stop-The-Word情況；而即便是最新的G1收集器也不例外。

• Java中一種全局暫停的現象,jvm掛起狀態

• 全局停頓，所有Java代碼停止，native代碼可以執行，但不能和JVM交互

• 多半由於jvm的GC引起，如：
  1.老年代空間不足。
  2.永生代（jkd7）或者元數據空間（jkd8）不足。
  3.System.gc()方法調用。
  4.CMS GC時出現promotion failed和concurrent mode failure
  5.YoungGC時晉升老年代的內存平均值大於老年代剩余空間
  6.有連續的大對象需要分配

• 除了GC還有以下原因：
  1.Dump線程--人為因素。
  2.死鎖檢查。
  3.堆Dump--人為因素。
  Full GC 是清理整個堆空間—包括年輕代和老年代。

4.1 GC時為什么會有全局停頓？

　　類比在聚會時打掃房間，聚會時很亂，又有新的垃圾產生，房間永遠打掃不干凈，只有讓大家停止活動了，才能將房間打掃干凈。當gc線程在處理垃圾的時候，其它java線程要停止才能徹底清除干凈，否則會影響gc線程的處理效率增加gc線程負擔，特別是在垃圾標記的時候。

4.2 危害

• 長時間服務停止，沒有響應

• 遇到HA系統，可能引起主備切換，嚴重危害生產環境。

• 新生代的gc時間比較短（），危害小。

• 老年代的gc有時候時間短，但是有時候比較長幾秒甚至100秒--幾十分鍾都有。

• 堆越大花的時間越長。

參考鏈接：

https://www.jianshu.com/p/d686e108d15f

https://zhuanlan.zhihu.com/p/73628158

https://blog.51cto.com/zhangjunhd/53092