Java final 關鍵字使用注意事項：從多態陷阱到內存模型

前言

final 看似簡單，實則暗藏多態陷阱、內存可見性保證、編譯期常量內聯等深層機制。本文針對實戰中易踩的坑，結合字節碼與 JMM（Java 內存模型）視角，給出避坑指南。

一、final 類與方法：繼承鏈的終點

1.1 final 類隱式最終化所有方法

類加 final 後，編譯器會為所有方法隱式添加 ACC_FINAL 標記，子類嘗試覆蓋直接編譯報錯。

1.2 private 方法隱式 final

私有方法不可見，子類同名方法不構成覆蓋，語義上等同 final。注意：若父類私有方法改為 protected/public，子類同名方法瞬間變為覆蓋，行為突變。

1.3 兩大使用動機

1. 語義鎖定：模板方法模式中骨架方法加 final，防止子類破壞流程。
2. 性能優化：早期版本依賴 final 內聯；現代 HotSpot 通過 CHA 對非 final 也大量內聯，但 final 提供確定性保證。

二、final 變數：引用不變 ≠ 對象不變

2.1 基本類型 vs 引用類型

• 基本類型：值不可變，真正常量。
• 引用類型：引用地址不可變（Type * const），對象內部狀態可變。
  例：final List<String> list = new ArrayList<>(); list.add("x"); // 合法

2.2 成員變數初始化鐵律

• 實例 final 字段：必須在聲明時、實例初始化塊、或每個構造器中完成賦值（若有 this() 鏈，僅首個構造器賦值）。
• 靜態 final 字段：聲明時或靜態初始化塊賦值。

2.3 局部變數與 lambda 捕獲

Java 8+ lambda 捕獲局部變數要求「實際上 final」（effectively final），即代碼中未重新賦值。編譯器將捕獲值複製到匿名類實例字段，生命周期脫離棧幀。

三、經典陷阱：構造器中調用非 final 方法導致字段未初始化

class Glyph {
    void draw() { System.out.println("Glyph.draw()"); }
    Glyph() { draw(); }
}
class RoundGlyph extends Glyph {
    private int radius = 1;
    RoundGlyph(int r) { radius = r; }
    void draw() { System.out.println("RoundGlyph.draw(), radius = " + radius); }
}
new RoundGlyph(5);
// 輸出：
// Glyph() before draw()
// RoundGlyph.draw(), radius = 0  ← 此處 radius 尚未賦值為 5！
// Glyph() after draw()
// RoundGlyph.RoundGlyph(), radius = 5

根因：父構造器執行時，子類字段仍處於默認值階段，多態調用子類覆蓋方法讀取到 0。
鐵律：構造器內只調用 final/private/static 方法，杜絕多態洩露半初始化對象。

四、final 內存語義與 JMM 保證

4.1 寫最終字段的重排序規則

JMM 保證：在構造器內對 final 字段的寫入，與將構造器的引用賦值給共享變數，之間不會重排序。即其他線程通過共享引用讀取對象時，必定能看到正確的 final 字段值，無需額外同步。

4.2 常量池與字段存儲差異

• 編譯期常量（static final 基本類型/String + 常量表達式）：編譯器內聯到調用處字節碼，每個使用類的常量池存一份副本，運行期不訪問原類字段。
• 運行期常量：存於方法區原類靜態字段表，運行期訪問字段指令獲取。

坑點：若修改庫中編譯期常量值而未重新編譯調用方，調用方仍用舊值（常量池副本），導致版本不一致。

五、總結：final 使用檢查清單

深入理解 final 的語義邊界與運行時保證，是寫出健壯、高性能 Java 代碼的關鍵能力。