JVM探秘：四種引用、對象的生存與死亡

本系列筆記主要基於《深入理解Java虛擬機：JVM高級特性與最佳實踐第2版》，是這本書的讀書筆記。 Java虛擬機的記憶體區域中，程式計數器、Java棧和本地方法棧是線程私有的，隨線程而生隨線程而滅，因此這幾個區域的記憶體回收和分配都有確定性，所以主要探究的是Java堆和方法區的記憶體分配及回收。 Ja ...

本系列筆記主要基於《深入理解Java虛擬機：JVM高級特性與最佳實踐第2版》，是這本書的讀書筆記。

Java虛擬機的記憶體區域中，程式計數器、Java棧和本地方法棧是線程私有的，隨線程而生隨線程而滅，因此這幾個區域的記憶體回收和分配都有確定性，所以主要探究的是Java堆和方法區的記憶體分配及回收。

Java堆

在Java堆中存放著所有的對象實例，垃圾收集器在對堆進行回收前，第一件事就是判斷這些對象中哪些還存活，哪些已經死去（即不會再被使用到的對象）。

Java中的引用

在JDK1.2及之前，關於引用的定義是這樣的：如果一塊記憶體中存儲的數值代表的是另外一塊記憶體的起始地址，就稱這塊記憶體代表一個引用（reference）。但是這種定義比較狹隘，一個對象就只有被引用和沒有被引用兩種狀態。還有這樣一種“食之無味，棄之可惜”的對象：當記憶體空間充足時，則能繼續保留在記憶體中，如果記憶體空間在垃圾收集後非常緊張，則可以拋棄這些對象。很多緩存功能都符合這樣的應用場景。

在JDK1.2之後，對引用的概念進行了擴充，將引用分為強引用（Strong Reference）、軟引用（Soft Reference）、弱引用（Weak Reference）、虛引用（Phantom Reference）4種，這4種引用強度依次遞減：

強引用（Strong Reference）就是在代碼中普遍存在的，類似“Object obj = new Object()”這類的引用，只要強引用還存在，垃圾收集器永遠不會回收被引用的對象。
軟引用（Soft Reference）是用來描述有用非必需的對象。軟引用關聯的對象，在系統將要發生記憶體溢出之前，將會對這些對象進行二次回收。如果這次回收後還沒有足夠的記憶體，才會拋出記憶體溢出異常。上面所說的“食之無味，棄之可惜”的對象就是屬於軟引用。
弱引用（Weak Reference）是用來描述非必需的對象，但是比軟引用更弱一些，弱引用關聯的對象只能生存到下一次垃圾收集發生之前。當下一次垃圾收集時，無論記憶體是否足夠，都會回收掉被弱引用關聯的對象。
虛引用（Phantom Reference）也稱為幽靈引用或者幻影引用，它是最弱的一種引用。一個對象是否有虛引用存在，完全不會對其生存時間造成任何影響，也無法通過虛引用獲得一個對象實例。為對象設置虛引用的目的，就是能在這個對象被收集器回收時收到一個系統通知。

引用計數演算法

很多書中判斷對象是否存活的演算法是這樣的：給對象中添加一個引用計數器，每當一個地方引用它，計數器值就加1；當引用失效時，計數器值就減1；任何時刻計數器為0 的對象就是不再被使用的。

引用記數演算法雖然實現簡單，判定效率也高，但是有一個弊端，就是它很難解決對象之間相互迴圈引用的問題。下麵的代碼中，objA和objB互相引用，如果使用引用計數法，這兩個對象的引用計數器值都為1，會導致垃圾收集器無法回收它們。

/**
 * 引用記數演算法測試
 * VM Args: -XX:+PrintGCDetails
 * Run With JDK 1.8
 * */
public class ReferenceCountingGC {

    public Object instance = null;
    private static final int _1M = 1024 * 1024;
    private byte[] bigSize = new byte[2 * _1M];

    public static void main(String[] args) {
        ReferenceCountingGC objA = new ReferenceCountingGC();
        ReferenceCountingGC objB = new ReferenceCountingGC();
        objA.instance = objB;
        objB.instance = objA;

        objA = null;
        objB = null;

        //這時發生GC，objA和objB能否被回收？
        System.gc();
    }
}

運行結果：

[GC (System.gc()) [PSYoungGen: 7432K->728K(38400K)] 7432K->736K(125952K), 0.0012008 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (System.gc()) [PSYoungGen: 728K->0K(38400K)] [ParOldGen: 8K->667K(87552K)] 736K->667K(125952K), [Metaspace: 3491K->3491K(1056768K)], 0.0044445 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
Heap
 PSYoungGen      total 38400K, used 333K [0x00000000d5c00000, 0x00000000d8680000, 0x0000000100000000)
  eden space 33280K, 1% used [0x00000000d5c00000,0x00000000d5c534a8,0x00000000d7c80000)
  from space 5120K, 0% used [0x00000000d7c80000,0x00000000d7c80000,0x00000000d8180000)
  to   space 5120K, 0% used [0x00000000d8180000,0x00000000d8180000,0x00000000d8680000)
 ParOldGen       total 87552K, used 667K [0x0000000081400000, 0x0000000086980000, 0x00000000d5c00000)
  object space 87552K, 0% used [0x0000000081400000,0x00000000814a6cf0,0x0000000086980000)
 Metaspace       used 3497K, capacity 4498K, committed 4864K, reserved 1056768K
  class space    used 387K, capacity 390K, committed 512K, reserved 1048576K

從運行結果看，GC日誌中包含“7432K->736K”，意味著虛擬機並沒有因為兩個對象互相引用就不回收它們，而說明虛擬機並不是通過引用計數演算法來判斷對象是否存活的。

可達性分析演算法

在很多程式語言的主流實現中，都是通過可達性分析（Reachability Analysis）來判定對象是否存活的。這個演算法的基本思想是：通過一系列的稱為“GC Roots”的對象作為起始點，從這些節點開始向下搜索，搜索所走過的路徑稱為引用鏈（Reference Chain），當一個對象到GC Roots沒有任何引用鏈相連（用圖論的話說就是從GC Roots到這個對象不可達）時，則證明此對象是不可用的。

如下圖所示，對象Object 5、Object 6、Object 7雖然互相關聯，但是它們到GC Roots是不可達的，所以它們將被判定為可回收的對象：

在 Java 中，可作為 GC Roots 的對象有以下幾種：

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

對象的自我救贖

在可達性分析演算法中不可達的對象也不是“必死無疑”的，這時它們會暫時處於“緩刑”階段，要真正宣告死亡，至少要經歷兩次標記過程：第一次標記是當進行可達性分析後發現沒有與GC Roots相連的引用鏈，就標記一次；然後如果對象覆蓋了finalize()方法並且還未執行過，對象就會被放入一個叫F-Queue的隊列中，會有一個單獨的線程依次執行隊列中對象的finalize()方法，finalize()方法是對象最後一次自我救贖的機會，只要跟GC Roots引用鏈上的任意對象建立關聯，就可逃脫死亡，F-Queue的隊列中的對象會被第二次標記。兩次標記過後如果對象還沒有逃脫，那基本上它就真的被回收了。

以下代碼是對象一次自我救贖的演示：

/**
 * 對象的一次自我救贖
 * 1. 對象可以在GC時自我救贖
 * 2. 這種機會只有一次，因為一個對象的finalize()方法至多會被調用一次
 * */
public class FinalizeEscapeGC {

    public static FinalizeEscapeGC SAVE_HOOK = null;

    public void isAlive(){
        System.out.println("yes, i am still alive");
    }

    @Override
    protected void finalize() throws Throwable{
        super.finalize();
        System.out.println("finalize method executed");
        //把自己賦值給類變數，即與GC Roots建立了關聯
        FinalizeEscapeGC.SAVE_HOOK = this;
    }

    public static void main(String[] args) throws Throwable{
        SAVE_HOOK = new FinalizeEscapeGC();

        //對象第一次自我救贖
        SAVE_HOOK = null;
        System.gc();
        Thread.sleep(500);
        if(SAVE_HOOK != null) {
            SAVE_HOOK.isAlive();
        } else {
            System.out.println("no, i am dead");
        }

        //第二次自我救贖失敗，因為finalize()只執行一次
        SAVE_HOOK = null;
        System.gc();
        Thread.sleep(500);
        if(SAVE_HOOK != null) {
            SAVE_HOOK.isAlive();
        } else {
            System.out.println("no, i am dead");
        }
    }
}

運行結果：

finalize method executed
yes, i am still alive
no, i am dead

從運行結果可知，SAVE_HOOK對象的finalize()方法確實被垃圾收集器觸發過，並且在被回收之前成功逃脫了。代碼中兩段相同的代碼，第二次沒有成功逃脫，是因為一個對象的finalize()方法只會被系統自動調用一次。另外，finalize()方法運行代價高昂，不確定性大，無法保證對象的調用順序，所以不建議使用此方法，可以用try-finally替代。

方法區

方法區也存在垃圾收集，只不過這塊記憶體區域的垃圾收集效率比較低。在JDK1.6及之前，方法區的垃圾收集主要回收兩部分內容：廢棄常量和無用的類。但在JDK1.7的時候運行時常量池挪到了Java堆中，所以現在方法區主要是回收無用的類。運行時常量的回收跟堆記憶體中其他對象的回收方法基本一致。

同時滿足以下三個條件，才會被判定為無用的類：

該類所有的實例都已經被回收，也就是Java堆中不存在該類的任何實例。
載入該類的ClassLoader已經被回收。
該類對應的java.lang.Class對象沒有在任何地方被引用，無法在任何地方通過反射訪問該類的方法。

虛擬機可以對滿足以上3個條件的無用類進行回收，也僅僅是“可以”，並不是一定會回收。是否對類進行回收，HotSpot虛擬機提供了-Xnoclassgc參數進行控制。在大量使用反射、動態代理、CGLib等ByteCode框架、動態生成JSP以及OSGi這類頻繁自定義ClassLoader的場景，都需要虛擬機具備類卸載的功能，以保證方法區不會溢出。

本文代碼的 Github Repo 地址：https://github.com/cellei/JVM-Practice