轉載：http://blog.csdn.net/canot/article/details/51037938

一、GC是如何判斷一個對象為”垃圾”的？

java堆內存中存放著幾乎所有的對象實例，垃圾收集器在對堆進行回收前，第一件事情就是要確定這些對象之中哪些還“存活”著，哪些已經“死去”。那么GC具體通過什么手段來判斷一個對象已經”死去”的？

1. 引用計數算法（已被淘汰的算法）

給對象中添加一個引用計數器，每當有一個地方引用它時，計數器值就加1；當引用失效時，計數器值就減1；任何時刻計數器的值為0的對象就是不可能再被使用的，將會被回收。

目前主流的java虛擬機都摒棄掉了這種算法，最主要的原因是它 很難解決對象之間相互循環引用的問題 。盡管該算法執行效率很高。

2. 可達性分析算法

目前主流的編程語言（java、C#等）的主流實現中，都是稱通過可達性分析（Reachability Analysis）來判定對象是否存活的。這個算法的基本思路：

通過一系列的稱為 “GC Roots” 的對象作為起始點，從這些節點開始向下搜索，搜索所走過的路徑稱為 引用鏈(Reference Chain) ，當一個對象到GC Roots沒有任何引用鏈相連（用圖論的話來說，就是從GC Roots到這個對象不可達）時，則證明此對象是不可用的。

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

這里寫圖片描述

在Java語言中，可作為GC Roots的對象包括下面幾種：

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

二、被GC判斷為“垃圾”的對象一定會被回收嗎？

即使在可達性分析算法中不可達的對象，也并非是“非死不可”的，這時候它們 暫時處于“緩刑”階段，要真正宣告一個對象死亡，至少要經歷兩次標記過程：

（1）如果對象在進行可達性分析后，發現沒有與GC Roots相連接的引用鏈，那它將會被第一次標記并且進行一次篩選，篩選的條件是此對象是否有必要執行finalize()方法。當對象沒有覆蓋finalize()方法，或者finalize()方法已經被虛擬機調用過，虛擬機將這兩種情況都視為“沒有必要執行”。（即意味著直接回收）

（2）如果這個對象被判定為有必要執行finalize()方法，那么 這個對象將會放置在一個叫做F-Queue的隊列之中，并在稍后由一個由虛擬機自動建立的、低優先級的Finalizer線程去執行它。 這里所謂的“執行”是指虛擬機會觸發這個方，但并不承諾會等待它運行結束。這樣做的原因是，如果一個對象在finalize()方法中執行緩慢，或者發生了死循環（更極端的情況），將很可能會導致F-Queue隊列中其他對象永久處于等待，甚至導致整個內存回收系統崩潰。

finalize()方法是對象逃脫死亡命運的最后一次機會，稍后GC將對F-Queue中的對象進行第二次小規模的標記，如果對象要在finalize()中成功拯救自己 —— 只要重新與引用鏈上的任何一個對象建立關聯即可，譬如把自己（this關鍵字）賦值給某個類變量或者對象的成員變量，那在第二次標記時它將被移除出“即將回收”的集合； 如果對象這時候還沒有逃脫，那基本上它就真的被回收了。

代碼示例：

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 mehtod executed!");
        FinalizeEscapeGC.SAVE_HOOK = this;
    }

    public static void main(String[] args) throws Throwable {
        SAVE_HOOK = new FinalizeEscapeGC();
        // 對象第一次成功拯救自己
        SAVE_HOOK = null;
        System.gc();
        // 因為finalize方法優先級很低,所以暫停0.5秒以等待它
        Thread.sleep(500);
        if (SAVE_HOOK != null) {
            SAVE_HOOK.isAlive();
        } else {
            System.out.println("no,i am dead:(");
        }
        // 下面這段代碼與上面的完全相同,但是這次自救卻失敗了
        SAVE_HOOK = null;
        System.gc();
        // 因為finalize方法優先級很低,所以暫停0.5秒以等待它
        Thread.sleep(500);
        if (SAVE_HOOK != null) {
            SAVE_HOOK.isAlive();
        } else {
            System.out.println("no,i am dead:(");
        }
    }
}

運行結果:

finalize mehtod executed!
yes,i am still alive :)
no,i am dead :(

SAVE_HOOK對象的finalize()方法確實被GC收集器觸發過，并且在被收集前成功逃脫了。另外一個值得注意的地方是，代碼中有兩段完全一樣的代碼片段，執行結果卻是一次逃脫成功，一次失敗。這是因為 任何一個對象的finalize()方法都只會被系統自動調用一次，如果對象面臨下一次回收，它的finalize()方法不會被再次執行，因此第二段代碼的自救行動失敗了。因為finalize()方法已經被虛擬機調用過，虛擬機都視為“沒有必要執行”。(即意味著直接回收)

《深入理解java虛擬機 JVM高級特性與最佳實踐》周志明