深度解析 Java 垃圾回收機制與 finalize 方法的真相

前言：別再依賴 finalize 了

許多 Java 開發者對 finalize() 存在誤解，以為它是 C++ 解構函數的對應物，可用於釋放資源。實則不然。本文將從 JVM 垃圾回收原理、finalize 執行機制、對象復活現象、現代替代方案四個維度，徹底講透這個「被誤解最深」的方法。

垃圾回收核心原理回顧

1. 可達性分析算法

現代 JVM（HotSpot）採用 根搜尋算法（GC Roots Tracing）：

• GC Roots 包含： 虛擬機棧引用的對象、方法區類靜態屬性/常量引用的對象、本地方法棧 JNI 引用的對象、同步鎖持有的對象等。
• 判定規則： 從 GC Roots 出發，沿引用鏈搜尋；無法到達的對象判定為「可回收」。

2. 主流 GC 算法

finalize 方法深度剖析

1. 方法簽名與調用時機

protected void finalize() throws Throwable

• 觸發條件： GC 發現對象不可達，且對象未曾執行過 finalize，且覆寫了非空 finalize。
• 執行線程： 由低優先級的 Finalizer 守護線程異步執行，不保證及時、甚至不保證執行。
• 執行次數： 生命周期僅一次。若對象在 finalize 中「復活」，下次 GC 不會再呼叫 finalize。

2. 對象生命周期狀態機

[可達] --GC 判定不可達--> [可終結] --進入 F-Queue--> [終結中] --finalize 執行完--> [已終結] --再次 GC 判定不可達--> [可回收]
                    ↑_________最終化復活_________|

3. 經典「對象復活」陷阱

public class ResurrectionDemo {
    static ResurrectionDemo obj; // GC Root 引用
    
    @Override
    protected void finalize() {
        System.out.println("finalize 執行，對象復活！");
        obj = this; // 重新掛載到 GC Root，對象復活
    }
    
    public static void main(String[] args) throws InterruptedException {
        obj = new ResurrectionDemo();
        obj = null; // 斷開引用
        System.gc();
        Thread.sleep(1000);
        System.out.println("第一次 GC 後：" + (obj != null ? "存活" : "已回收"));
        
        obj = null; // 再次斷開
        System.gc();
        Thread.sleep(1000);
        System.out.println("第二次 GC 後：" + (obj != null ? "存活" : "已回收")); // 不會再執行 finalize
    }
}

輸出：

finalize 執行，對象復活！
第一次 GC 後：存活
第二次 GC 後：已回收  ← finalize 不再執行，直接回收

為什麼不推薦使用 finalize？

1. 執行時機不可控： GC 觸發不確定，可能導致資源長期佔用（檔案句柄、資料庫連線、Socket）。
2. 效能開銷大： 需進入 F-Queue、由專門線程處理、可能觸發額外 GC 週期。
3. 異常吞沒風險： finalize 拋出的異常會被 JVM 忽略，導致錯誤靜默失敗。
4. 對象復活破壞語義： 違背「不可達即可回收」直覺，極易產生難以排查的 Bug。
5. JDK 9 標記棄用： @Deprecated(since="9", forRemoval=true)，未來版本可能移除。

現代資源管理最佳實踐

1. try-with-resources (JDK 7+) —— 首選方案

// 自動實作 AutoCloseable，離開作用域自動 close()
try (FileInputStream fis = new FileInputStream("data.txt");
     BufferedReader br = new BufferedReader(new InputStreamReader(fis))) {
    String line;
    while ((line = br.readLine()) != null) {
        System.out.println(line);
    }
} catch (IOException e) {
    e.printStackTrace();
}
// 編譯器自動生成 finally 區塊調用 close()

2. 显式 close() / shutdown() 模式

為資源類提供 close() 方法，調用方在 finally 區塊確保釋放：

public class DbConnection implements AutoCloseable {
    private Connection conn;
    
    public void close() {
        if (conn != null) {
            try { conn.close(); } catch (SQLException ignore) {}
        }
    }
}

// 使用
DbConnection db = new DbConnection();
try {
    // 業務操作
} finally {
    db.close(); // 確保釋放
}

3. Cleaner API (JDK 9+) —— 替代 finalize 的現代化機制

import java.lang.ref.Cleaner;

public class ResourceHandler implements AutoCloseable {
    private static final Cleaner cleaner = Cleaner.create();
    private final Cleaner.Cleanable cleanable;
    private final Resource resource; // 外部資源
    
    public ResourceHandler(Resource res) {
        this.resource = res;
        // 註冊清理動作，當對象變為 phantom reachable 時執行
        this.cleanable = cleaner.register(this, () -> {
            resource.release(); // 安全釋放資源
        });
    }
    
    @Override
    public void close() {
        cleanable.clean(); // 手動觸發清理
    }
}

• 基於 PhantomReference，不阻塞 GC，執行更可預測。
• 清理動作在專用線程執行，避免 finalize 的線程爭用問題。

4. 弱引用緩存場景

若需實現「記憶體緊張時自動清理」的緩存，請用 WeakHashMap 或 Guava Cache/Caffeine，而非 finalize。

總結

• finalize() 是歷史包袱，不要在新代碼中使用。
• 資源釋放請用 try-with-resources 或顯式 close() 模式。
• 極少數需「對象不可達時執行清理」的場景，請用 Cleaner API。
• 理解 GC 根搜尋、分代收集、引用類型（強/軟/弱/虛），才是掌握 Java 記憶體管理的核心鑰匙。