Java finalize() 方法詳解：最終化機制、執行不確定性、資源洩漏風險與替代方案

finalize() 是 Object 的受保護方法，旨在對象被 GC 回收前提供「最後機會」釋放非內存資源（文件句柄、Socket、Native 內存）。但因執行時間不確定、線程不確定、異常吞沒、性能開銷大，已被 JDK 9 標記為棄用，JDK 18 移除 finalize 實現。本文詳解其機制、風隀與現代替代方案。

一、finalize() 機制與執行流程

protected void finalize() throws Throwable {
    try {
        // 釋放非內存資源
        if (fileHandle != null) closeFile();
    } finally {
        super.finalize(); // 必須調用父類 finalize
    }
}

GC 與最終化隊列交互

1. 對象變為不可達
2. GC 發現對象覆寫了 finalize() 且未被最終化
3. 對象移入「最終化隊列」
4. 低優先級 Finalizer 線程逐個調用 finalize()
5. finalize() 完成 → 對象再次變為不可達
6. 下輪 GC 真正回收內存

關鍵特徵

• 至多執行一次：對象復活（thisRef = this）也不會再次調用。
• 線程不確定：由 JVM 專用 Finalizer 線程執行，非業務線程。
• 時間不確定：可能延遲任意長，甚至程序結束前永不執行。
• 異常吞沒：finalize() 拋出異常會被忽略，最終化過程終止，對象可能處於不一致狀態。
• 阻塞 Finalizer 線程：finalize() 中睡眠/死鎖會導致所有對象最終化停滯，引發 OOM。

二、經典反面教材：finalize() 復活對象

class Zombie {
    static Zombie ref;
    @Override protected void finalize() {
        ref = this; // 復活：重新變為可達
        System.out.println("我復活了！");
    }
}
public class ResurrectionDemo {
    public static void main(String[] args) throws InterruptedException {
        Zombie z = new Zombie();
        z = null;
        System.gc(); Thread.sleep(100);
        System.out.println("第一次 GC 後: " + (Zombie.ref != null ? "存活" : "已死"));

        Zombie.ref = null; // 再次不可達
        System.gc(); Thread.sleep(100);
        System.out.println("第二次 GC 後: " + (Zombie.ref != null ? "存活" : "已死")); // 不會再次 finalize
    }
}

三、為什麼棄用？JDK 9+ 官方聲明核心理由

1. 不可靠：無法保證及時/一定執行，資源釋放失效風險極高。
2. 性能殺手：最終化對象需經歷多輪 GC，分配/回收開銷比普通對象大 10-100 倍。
3. 線程安全陷阱：Finalizer 線程與業務線程併發訪問對象狀態，極難正確同步。
4. 替代方案成熟：try-with-resources、Cleaner、PhantomReference 更安全、可控。

四、現代替代方案對比

五、Cleaner 實戰範例

class NativeResource implements AutoCloseable {
    private final long nativeHandle; // 假設 Native 分配的內存地址
    private final Cleaner.Cleanable cleanable;

    NativeResource(long size) {
        this.nativeHandle = NativeLib.alloc(size);
        // 註冊清理動作：JVM 會在對象不可達後由 Cleaner 線程執行
        this.cleanable = Cleaner.create(this, () -> NativeLib.free(nativeHandle));
    }

    public void close() { cleanable.clean(); } // 手動提前清理

    // 無 finalize()！
}

六、避坑指南：存量代碼如何遷移

1. 掃描所有 finalize()：IDE 搜索 protected void finalize。
2. 分類資源類型：作用域明確 → AutoCloseable；非作用域/堆外 → Cleaner。
3. 重構步驟：
   1. 實現 AutoCloseable，將清理邏輯移入 close()。
   2. 調用點包裝為 try (Resource r = ...) { ... }。
   3. 刪除 finalize()，添加 @Deprecated(forRemoval=true) 標註類。
   4. 若無法確定作用域，改用 Cleaner 註冊清理動作。
4. 測試驗證：壓測確認無 Native 內存洩漏、Finalizer 隊列無堆積。

七、總結

finalize() 是 Java 早期設計的歷史包袱。現代 Java (JDK 9+) 開發嚴禁使用。請牢記：資源釋放要確定、要可控、要在業務線程完成。try-with-resources 解決 90% 場景，Cleaner 解決剩餘 10%，徹底告別最終化噩夢。

1. 上一篇文章： Java 線程同步與線程間通信深度解析：synchronized、Lock、wait/notify、Condition、生產者消費者模式
2. 下一篇文章： Java finalize() 方法詳解：最終化機制、執行不確定性、資源洩漏風險與替代方案

Java 相關知識

Java JDBC 連接 MySQL 完整入門：驅動載入、連接池、CRUD 範本與資源管理鐵律

JDBC (Java Database Connectivi

Java 加密技術（五）：DH 密鑰一致協議——雙方安全通信的數學基石與代碼實現

Diffie-Hellman (DH) 算法由公鑰密碼奠基人

JBuilder 2007 開發 Web Services 全流程：從 WSDL 設計到客戶端生成

Web Services 以軟件為服務對象，區別於面向人的

靈活運用 EJB 本地與遠端介面 (一)：架構設計動機與應用藍圖

EJB 2.0 規範引入本地介面，賦予企業級 Java 組件