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

本系列筆記主要基於《深刻理解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 五、Object 六、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