摘要

Java程式在運行程序中會產生大量的物件，但是記憶體大小是有限的，如果光用而不釋放，那記憶體遲早被耗盡，如C、C++程式，需要程式員手動釋放記憶體，Java則不需要，是由垃圾回收器去自動回收，

垃圾回收器回收記憶體至少需要做兩件事情：標記垃圾、回收垃圾，于是誕生了很多演算法及垃圾回收器，

垃圾判斷演算法

即判斷JVM中的所有物件，哪些物件是存活的，哪些物件可回收的演算法，

參考計數演算法

在物件中添加一個屬性用于標記物件被參考的次數，每多一個其他物件參考，計數+1，當參考失效時，計數-1，如果計數=0，表示沒有其他物件參考，就可以被回收，

這個演算法無法解決回圈依賴的問題，

可達性分析演算法

通過一系列被稱為“GC Roots”的根物件作為起始節點集，從這些節點開始，根據參考關系鏈向下搜索，如果某個物件無法被搜索到，則說明該物件無參考執行，可回收，相反，則物件處于存活狀態，不可回收，

JVM中的實作是找到存活物件，未打標記的就是無用物件，GC時會回收，

哪些物件可以作為GC Root呢：

所有Java執行緒當前活躍的堆疊幀里指向GC堆里的物件的參考；換句話說，當前所有正在被呼叫的方法的參考型別的引數/區域變數/臨時值，
VM的一些靜態資料結構里指向GC堆里的物件的參考，例如說HotSpot VM里的Universe里有很多這樣的參考，
JNI handles，包括global handles和local handles
（看情況）所有當前被加載的Java類
（看情況）Java類的參考型別靜態變數
（看情況）Java類的運行時常量池里的參考型別常量（String或Class型別）
（看情況）String常量池（StringTable）里的參考

垃圾回收演算法

1、標記-清除演算法

概念：

顧名思義，標記-清除演算法分為兩個階段，標記(mark)和清除(sweep)，

標記：遍歷所有的GC Roots，然后將所有的GC Roots可達的物件標記為存活的物件，

清除：清除的程序將遍歷所有堆中的物件，將沒有標記的物件全部清除，

圖解：

對上圖中的黃色部分進行垃圾回收，回收后的截圖如下所示：

從圖中可知，進行標記清理后，可用記憶體增加，但是清除垃圾后的記憶體地址不連接，出現垃圾碎片，

缺點：

1、執行效率不穩定，如果Java堆中包含大量物件，而且大部分是需要被回收的，這時必須記性大量標記及清除動作，導致標記和清除兩個程序執行效率都隨物件數量增長而降低，

2、記憶體空間碎片化的問題，標記、清除后會產生大量的不連續記憶體碎片，空間碎片太可能會導致當以后需要分配大物件時無法找到足夠的連續記憶體二不得不提前觸發另一次垃圾收集動作，

2、標記-復制演算法

概念：

復制演算法將記憶體分為兩個區間,這兩個區間是動態的，在任意一個時間點，所有分配的物件記憶體只能在其中一個區間（活動區間），另外一個區間就是空閑區間，
當有效記憶體空間耗盡時，JVM將暫停程式運行，開啟復制演算法GC執行緒，GC執行緒會將活動區間內的存活物件，全部復制到空閑區間，且嚴格按照記憶體地址一次排列，與此同時，GC執行緒將更新存活物件的記憶體參考地址指向新的記憶體地址，這個時候空閑記憶體已經變成了活動區間，垃圾物件全部在原來的活動區間，清理掉垃圾物件，原活動區間就變成了空閑區間，

這種方式記憶體的代價太高，每次基本上都要浪費一半的記憶體，于是將該演算法進行了改進，記憶體區域不再是按照1：1去劃分，而是將記憶體劃分為8:1:1三部分，較大那份記憶體是Eden區，其余是兩塊較小的記憶體區叫Survior區，每次都會優先使用Eden區，若Eden區滿，就將物件復制到第二塊記憶體區上，然后清除Eden區，如果此時存活的物件太多，以至于Survivor不夠時，會將這些物件通過分配擔保機制復制到老年代中，(java堆又分為新生代和老年代)，

圖解：

優點：

1、很好地解決了“標記-清除”演算法，記憶體布局混亂的缺點，

缺點：
1、浪費一半的記憶體，

2、假設物件存活率為100%，那么“標記-復制”演算法的GC程序就是重復的把物件復制一遍，而且將所有的參考地址重置一遍，可以預見的復制所消耗的時間隨著物件存活率達到一定程度將會變成災難，所以“標記-復制”演算法使用的場景是可以忍受只是用50%記憶體，物件存活率非常低

3、標記-整理演算法

概念：

標記程序仍然與“標記-清除”演算法一樣，但后續步驟不是直接對可回收物件進行清理，而是讓所有存活的物件都向一端移動，然后直接清理掉端邊界以外的記憶體，

圖解：

優點：

1、彌補了“標記-清除”演算法，記憶體區域分散的缺點
2、彌補了“標記-復制”演算法記憶體減半的代價

缺點：

1、效率不高，對于“標記-清除”而言多了整理作業，

4、分代收集演算法

當前商業虛擬機的垃圾收集都采用分代收集，此演算法沒啥新鮮的，就是將上述三種演算法整合了一下，具體如下：
根據各個年代的特點采取最適當的收集演算法

1、在新生代中，每次垃圾收集時都發現有大批物件死去，只有少量存活，那就選用復制演算法，只需要付出少量存活物件的復制成本就可以完成收集，
2、老年代中因為物件存活率高、沒有額外空間對他進行分配擔保，就必須用標記-清除或者標記-整理，

測驗案例

以下測驗采用的是Serial加Serial Old收集器組合，

查看當前jdk默認額收集器使用以下陳述句，

java -XX:+PrintCommandLineFlags -version

執行結果：

1、物件優先在Eden分配

測驗代碼：

/**
 * @Description 物件優先在Eden分配
 * VM引數：-verbose: gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:+UseSerialGC
 */
public class AllocationMemory {
    private  static final int _1MB=1024 * 1024;

    public static void main(String[] args) {
        byte[] allocation1,allocation2,allocation3;
        allocation1=new byte[3 * _1MB];
        allocation2=new byte[2 * _1MB];
        allocation3=new byte[5 * _1MB];
    }
}

測驗結果：

原因分析：

* eden 8M
* from 1M
* to 1M
* 老年代 10M

allocation1=new byte[3 * _1MB];

執行此行代碼時，新生代Eden為空，滿足分配3M的需求
執行完成后，allocation1指向的物件在新生代Eden區；

allocation2=new byte[2 * _1MB];

執行此行代碼時，新生代Eden包含3M的物件，滿足分配2M的需求
執行完成后，allocation2指向的物件在新生代Eden區；

allocation3=new byte[5 * _1MB];

對allocation3分配記憶體時，發現Eden已經占用5MB，剩余的空間不滿足分配allocation3需要的5MB記憶體，因此發生了Minor GC，
從測驗結果的圖中Minor GC發生時記憶體變化可以看出，新生代記憶體從7679K變化成608K，新生代的記憶體使用量基本清空了，
而整個堆的大小從7679K變化成5728K，堆區的使用量仍然包含5MB的資料，可以判斷出之前的5MB資料從新生代復制到了老年代了，
又因為新生代的servivor區的from區和to區分別各站1MB的記憶體，根本不足以放下2MB和3MB的物件，所以物件優先在Eden區分配，
執行垃圾回收后，新生代Eden區清空，滿足分配5M的需求，allocation3指向的物件在新生代Eden區，
因此程式執行完成后，堆區的情況是：
eden space 8192K, 63% --包含allocation3 指向的5MB物件
the space 10240K, 50% 　--包含 allocation1、allocation2指向的物件，　　　　　　　　　　

2、大物件直接進入老年代

測驗代碼：

/**
 * @Description 大物件直接進入老年代
 * VM引數：-verbose: gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:+UseSerialGC
 * -XX:PretenureSizeThreshold=3145728
 */
public class PretenureSizeThreshold {
    private  static final int _1MB=1024 * 1024;

    public static void main(String[] args) {
        byte[] allocation;
        allocation= new byte[4 * _1MB];
    }
}

測驗結果：

原因分析：

虛擬機提供了-XX:PretenureSizeThreshold引數，制定大于該設定值的物件直接進入老年代，

從測驗結果中可以看出老年代占用了4MB空間，新生代Eden區占用不足4MB，因此可以判斷生成的4MB物件是在老年代，這是因為-XX:PretenureSizeThreshold被設定為3MB，因此超過3MB的物件都會直接在老年代進行分配，

3、長期存活的物件將進入老年代

測驗代碼

public class TenuringThreshold {
    public static final int _1Mb =1024*1024;

    public static void main(String[] args) {     
        byte[] alloctation1=new byte[_1Mb/4];
        byte[] alloctation2=new byte[8 * _1Mb];
        byte[] alloctation3=new byte[8 * _1Mb];
        alloctation3=null;
        alloctation3=new byte[8 * _1Mb];

    }
}

測驗結果：

1、VM引數：-verbose: gc -Xms40M -Xmx40M -Xmn20M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:+UseSerialGC -XX:MaxTenuringThreshold=1 -XX:+PrintTenuringDistribution

2、VM引數：-verbose: gc -Xms40M -Xmx40M -Xmn20M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:+UseSerialGC -XX:MaxTenuringThreshold=15 -XX:+PrintTenuringDistribution

原因分析：

1、VM引數：-verbose: gc -Xms40M -Xmx40M -Xmn20M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:+UseSerialGC -XX:MaxTenuringThreshold=1 -XX:+PrintTenuringDistribution

eden 16M

from 2M

to 2M

老年代 20M

程式執行完后, allocation1 指向的物件在老年代， allocation2 在老年代， allocation3 先指向的物件被垃圾回收了， allocation3后指向的物件在eden區，

byte[] alloctation1=new byte[_1Mb/4];
* 執行完后，allocation1 指向的物件在新生代的Eden區；
byte[] alloctation2=new byte[8 * _1Mb];
* 執行完后，allocation2 指向的物件在新生代的Eden區；
byte[] alloctation3=new byte[8 * _1Mb];
* 因為eden區不足需要分配的8M空間，所以觸發了young GC，
* GC發生后，allocation1 指向的物件從eden區復制到servivor區，allocation2所指向的物件，因為servivor區空間不夠分配，觸發空間擔保，進入老年代，
* GC完成后 alloctation3 指向的物件在新生代的Eden區；
alloctation3=null;
alloctation3=new byte[8 * _1Mb];
* 因為Eden區不足需要分配的8M空間，所有觸發了young GC
* GC發生后，eden區中的8M物件因為GC Root未可達，所有判斷為死物件，被垃圾回收器回收， allocation1 指向的物件因未達到1次的年齡限制，所以復制到了老年代，
* allocation2所指向的物件仍然指向老年代，
* GC完成后，eden區滿足8M物件分配的空間要求，alloctation3 指向的物件在新生代的Eden區；

2、VM引數：-verbose: gc -Xms40M -Xmx40M -Xmn20M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:+UseSerialGC -XX:MaxTenuringThreshold=15 -XX:+PrintTenuringDistribution

*程式執行完后, allocation1 指向的物件在 servivor區， allocation2 在老年代， allocation3 先指向的物件被垃圾回收了， allocation3后指向的物件在eden區，

byte[] alloctation1=new byte[_1Mb/4];
* 執行完后，allocation1 指向的物件在新生代的Eden區；
byte[] alloctation2=new byte[8 * _1Mb];
* 執行完后，allocation2 指向的物件在新生代的Eden區；
byte[] alloctation3=new byte[8 * _1Mb];
* 因為eden區不足需要分配的8M空間，所以觸發了young GC，
* GC發生后，allocation1 指向的物件從eden區復制到servivor區，allocation2所指向的物件，因為servivor區空間不夠分配，觸發空間擔保，進入老年代，
* GC完成后 alloctation3 指向的物件在新生代的Eden區；
alloctation3=null;
alloctation3=new byte[8 * _1Mb];
* 因為Eden區不足需要分配的8M空間，所有觸發了young GC
* GC發生后，eden區中的8M物件因為GC Root未可達，所有判斷為死物件，被垃圾回收器回收， allocation1 指向的物件因未達到15次的年齡限制，仍然在servivor區，
* allocation2所指向的物件仍然指向老年代，
* GC完成時，eden區滿足8M物件分配的空間要求，alloctation3 指向的物件在新生代的Eden區；

4、動態年齡判斷

測驗代碼：

/**

 * VM引數：-verbose: gc -Xms40M -Xmx40M -Xmn20M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:+UseSerialGC
 *  *  *  -XX:MaxTenuringThreshold=15 -XX:+PrintTenuringDistribution

 * @Version 1.0
 */
public class SpaceGuarantee {
    public static final int _1MB=1024 * 1024;

    public static void main(String[] args) {

        byte[] alloctation1=new byte[_1MB/4];
        //屏蔽#1此行代碼后，就不會觸發動態年齡判斷了，
        //byte[] alloctation2=new byte[_1MB/4]; //#1
        byte[] alloctation3=new byte[8 * _1MB];
        byte[] alloctation4=new byte[8 * _1MB];
        alloctation4=null;
        alloctation4=new byte[8 * _1MB];
    }
}

測驗結果：

1、未屏蔽 #1 處代碼

2、屏蔽 #1 處代碼

原因分析：

通過兩個結果的對比，發下在沒有屏蔽#1處代碼的情況下，Servivor區占用為0%，而老年代比預期占用的高，也就說明了survivor區的資料在經歷第二次GC的年齡計算就全部轉入到老年代了，并沒有等到15歲的臨界年齡，

而屏蔽了#1處代碼的情況下，Servivor區占用為38%，而老年代與預期值相似，說明servivor區的資料經歷第二次GC的年齡計算沒有復制到老年代，

這是因為沒有屏蔽#1處代碼的情況下，allocation1、allocation2兩個物件加起來達到了512K，并且他們是同年齡的，滿足同年物件達到Servivor區空間一半的規則，

byte[] alloctation1=new byte[_1MB/4];
* 新生代Eden區滿足256K物件的空間需求， allocation1 指向的物件被分配到新生代的eden區
byte[] alloctation2=new byte[_1MB/4];
* 新生代Eden區滿足256K物件的空間需求， allocation2 指向的物件被分配到新生代的eden區
byte[] alloctation3=new byte[8 * _1MB];
* 新生代Eden區滿足8MB物件的空間需求， allocation3 指向的物件被分配到新生代的eden區
byte[] alloctation4=new byte[8 * _1MB];
* 需要分配8MB的記憶體到新生代的eden區，Eden區空間不足，觸發young GC，
* GC發生后，allocation1 指向的物件被復制到新生代的servivor區，allocation2指向的物件被復制到新生代的servivor區，
* allocation3指向的物件因為servivor區不足以放下8MB的物件，所以觸發空間擔保，被復制到老年代中，
* GC完成后，allocation4指向的物件被分配到新生代的Eden區，
alloctation4=null;
alloctation4=new byte[8 * _1MB];
* 需要分配8MB的記憶體到新生代的eden區，Eden區空間不足，發生young GC，
* GC發生后，allocation1 指向的物件本應該繼續保留在servivor區中，但是因為servivor區中相同年齡所有物件的大小的總和大于servivor空間的一半，因此觸發了動態年齡判斷，所以被復制到老年代，
* allocation2 指向的物件本應該繼續保留在servivor區中，但是因為servivor區中相同年齡所有物件的大小的總和大于servivor空間的一半，因此觸發了動態年齡判斷，所以被復制到老年代，
* eden區中的8M物件因為GC Root未可達，所有判斷為死物件，被垃圾回收器回收，
* GC完成后，eden區滿足8M物件分配的空間要求，alloctation4 指向的物件在新生代的Eden區；

5、空間分配擔保

測驗代碼：

/**
 *  VM引數：-verbose: gc -Xms40M -Xmx40M -Xmn20M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:+UseSerialGC
 *  eden 16M
 *  from  2M
 *  to  2M
 *  老年代   20M
 *
 * @Version 1.0
 */
public class HandlePromotion {
    public static final int _1MB = 1024*1024;

    public static void main(String[] args) {
        byte[] allocation1=new byte[4*_1MB];
        byte[] allocation2=new byte[4*_1MB];
        byte[] allocation3=new byte[4*_1MB];
        allocation1=null;

        byte[] allocation4=new byte[4*_1MB];
        byte[] allocation5=new byte[4*_1MB];
        byte[] allocation6=new byte[4*_1MB];

        allocation4=null;//#1
        allocation5=null;//#2
        allocation6=null;//#3

        byte[] allocation7=new byte[4*_1MB];
    }

}

測驗結果：

1、未注釋#1，#2，#3 三行代碼的情況

2、注釋#1，#2，#3 三行代碼的情況

原因分析：

對比未注釋#1，#2，#3 三行代碼的情況與注釋#1，#2，#3 三行代碼的情況發現
未注釋#1，#2，#3 三行代碼的情況下發生了兩次Minor GC，
而注釋#1，#2，#3 三行代碼的情況下發生了兩次Minor GC，并且第二Minor GC執行時因空間擔保失敗而引發了一次Full GC，

執行byte[] allocation4=new byte[4*_1MB]代碼，需要向Eden區申請4MB記憶體空間，因為Eden空間不足分配，觸發第一次GC，
在發生minor GC之前，虛擬機檢查老年代20M記憶體，之前沒有晉升到過老年代的物件，因此滿足需求，所有發生Minor GC，
在此次GC中，Eden區會清除掉原來allocation1指向的4MB記憶體區，allocation2、allocation3指向的記憶體因Servivor無法滿足分配
因此被復制到新生代，此次從新生代復制到老年代的記憶體為8MB，

未注釋#1，#2，#3 三行代碼的情況下，執行byte[] allocation7=new byte[4*_1MB]代碼，需要向Eden區申請4MB記憶體，但Eden區記憶體無法滿足，因此觸發了第二次GC，
在發生minor GC之前，虛擬機先檢查老年代最大可用空間為12M，大于晉升的平均值8M，因此滿足空間擔保需求，所有發生Minor GC，
在此次GC中，Eden區中 allocation4 、allocation5、allocation6所指向的物件，因為成為了非存活物件，所有被清楚了，
執行完GC后，allocation7 指向的物件被分配到Eden區，

注釋#1，#2，#3 三行代碼的情況下，執行byte[] allocation7=new byte[4*_1MB]代碼，需要向Eden區申請4MB記憶體，但Eden區記憶體無法滿足，因此觸發了第二次GC，
在發生minor GC之前，虛擬機先檢查老年代剩余最大可用空間大于晉升的平均值8M，因此滿足空間擔保需求，所有發生Minor GC，
在此次GC中，Eden區中 allocation4 、allocation5、allocation6所指向的物件都存活物件，所以需要復制到Servivor區，但Servivor區不足以放下4MB大小的物件，需要晉升到老年代，

但老年代剩余可用空間不夠放下此次晉升的物件，因此引發了Full GC，

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/17416.html

標籤：Java

上一篇：《spring原始碼解讀》 - IoC 之決議 import 標簽

下一篇：maven~生成spotbug檔案

JVM 垃圾收集演算法 標記-清楚、標記-復制、標記-整理

摘要

垃圾判斷演算法

參考計數演算法

可達性分析演算法

垃圾回收演算法

1、標記-清除演算法

2、標記-復制演算法

3、標記-整理演算法

4、分代收集演算法

測驗案例

執行結果：

1、物件優先在Eden分配

測驗代碼：

測驗結果：

原因分析：

2、大物件直接進入老年代

測驗代碼：

測驗結果：

原因分析：

3、長期存活的物件將進入老年代

測驗代碼

測驗結果：

4、動態年齡判斷

測驗代碼：

測驗結果：

原因分析：

5、空間分配擔保

測驗代碼：

測驗結果：

原因分析：

JVM 垃圾收集演算法標記-清楚、標記-復制、標記-整理