Java 開發者注意！JEP 500 將徹底改變 `final` 字段的使用方式詳情 - java,開發語言,Java新特性,final,不可變,Oracle,數據庫 mizeyar 博客

Java 開發者注意！JEP 500 將徹底改變 `final` 字段的使用方式

Java 開發者們，你們是否曾經因為反射修改 final 字段而頭疼不已？現在，JEP 500 來了，它將徹底改變這一局面，讓 final 字段真正不可變！這對於 Java 生態系統來説，可是一個重大變革哦。

文章目錄

Java 開發者注意！JEP 500 將徹底改變 `final` 字段的使用方式

1. 背景：`final` 字段的煩惱
2. JEP 500：讓 `final` 字段真正不可變

2.1 JDK 26 的變更
2.2 啓用 `final` 字段修改
2.3 控制 `final` 字段限制的效果
2.4 `final` 字段修改的警告
2.5 識別修改 `final` 字段的代碼

3. 深度反射 API 的行為變更
4. 相關方法的行為變更
5. 序列化庫的替代方案
6. 對其他庫和框架的建議
7. 克隆方法的實現建議
8. 從本地代碼修改 `final` 字段
9. 風險與假設
10. 替代方案

10.1 依賴推測優化
10.2 指定允許被修改的模塊
10.3 指定修改和被修改的模塊

11. 總結
12. 致謝

1. 背景：`final` 字段的煩惱

在 Java 中，final 字段原本是用來表示不可變狀態的，一旦賦值就不能再修改。這種不可變性在多線程環境中非常關鍵，能確保對象的安全初始化，還能讓 JVM 進行性能優化，比如常量摺疊。然而，Java 的反射 API 卻允許通過一些手段修改 final 字段，這不僅破壞了代碼的正確性預期，還限制了 JVM 的性能優化空間。

舉個例子，假設我們有一個類 C，其中有一個 final 字段 x。正常情況下，x 的值在構造函數中賦值後就不應該再改變。但通過反射，我們可以輕易地修改它的值，這簡直是對 final 字段不可變性的“挑釁”！

class C {
    final int x;
    C() { x = 100; }
}

通過反射，我們竟然可以將 x 的值從 100 改為 200，甚至 300！

java.lang.reflect.Field f = C.class.getDeclaredField("x");
f.setAccessible(true);      // 使 C 的 final 字段可變
C obj = new C();
System.out.println(obj.x);  // 打印 100
f.set(obj, 200);
System.out.println(obj.x);  // 打印 200
f.set(obj, 300);
System.out.println(obj.x);  // 打印 300

這種行為不僅讓代碼變得不可靠，還可能引發各種潛在的錯誤。而且，這種能力還和序列化庫的需求衝突，因為序列化庫在反序列化時需要修改字段來初始化對象。

2. JEP 500：讓 `final` 字段真正不可變

為了解決這個問題，JEP 500 提出了一個方案，讓 final 字段真正不可變。這個方案的核心思想是，在未來的 JDK 版本中，默認情況下不允許通過反射修改 final 字段。開發者如果需要修改 final 字段，必須在啓動時顯式啓用這一能力。這樣一來，final 字段的不可變性就得到了保障，同時也為 JVM 的性能優化提供了更多空間。

2.1 JDK 26 的變更

在 JDK 26 中，將限制深度反射，使得默認情況下修改 final 字段會在運行時發出警告。不能簡單地通過使用 --add-opens 來啓用帶有 final 字段的類的深度反射來避免警告。

2.2 啓用 `final` 字段修改

應用開發者可以通過命令行選項或替代方法啓用特定 Java 代碼的 final 字段修改，以避免警告和未來的異常。啓用 final 字段修改表明應用需要修改 final 字段，並解除選定的 final 字段限制。

為類路徑上的任何代碼啓用 final 字段修改，無論 final 字段在哪裏聲明，使用以下命令行選項：

$ java --enable-final-field-mutation=ALL-UNNAMED ...

為模塊路徑上的特定模塊啓用 final 字段修改，再次傳遞一個以逗號分隔的模塊名稱列表：

$ java --enable-final-field-mutation=M1,M2 ...

啓用模塊的 final 字段修改並不能保證模塊中的代碼能夠通過深度反射修改 final 字段。要被修改的任何 final 字段還必須對執行深度反射的代碼開放。

2.3 控制 `final` 字段限制的效果

如果代碼位於未啓用 final 字段修改的模塊中，或者代碼所在的模塊未對字段的包開放，則代碼通過深度反射修改 final 字段是非法的。當嘗試非法修改 final 字段時，Java 運行時採取的操作由新的命令行選項 --illegal-final-field-mutation 控制。這個選項與 JDK 9 中 JEP 261 引入的 --illegal-access 選項以及 JDK 24 中 JEP 472 引入的 --illegal-native-access 選項在精神和形式上類似，其工作方式如下：

--illegal-final-field-mutation=allow：允許修改而不發出警告。
--illegal-final-field-mutation=warn：允許修改，但當特定模塊中的代碼首次執行非法 final 字段修改時發出警告。每個模塊最多發出一個警告。這是 JDK 26 中的默認模式。它將在未來的版本中逐步淘汰，並最終被移除。
--illegal-final-field-mutation=debug：與 warn 相同，但為每次非法 final 字段修改同時發出警告消息和堆棧跟蹤。
--illegal-final-field-mutation=deny：將導致 Field::set 為每次非法 final 字段修改拋出 IllegalAccessException。這種模式將在未來的版本中成為默認模式。

當 deny 成為默認模式時，allow 將被移除，但 warn 和 debug 至少在下一個版本中仍受支持。

2.4 `final` 字段修改的警告

當代碼嘗試非法修改 final 字段時，默認情況下，修改會成功，但 Java 運行時會發出警告，標識調用者：

WARNING: Final field f in p.C has been [mutated/unreflected for mutation] by class com.foo.Bar.caller in module N (file:/path/to/foo.jar)
WARNING: Use --enable-final-field-mutation=N to avoid a warning
WARNING: Mutating final fields will be blocked in a future release unless final field mutation is enabled

默認情況下，對於任何特定模塊，最多發出一個這樣的警告，僅當該模塊尚未發出警告時才會發出。警告寫入標準錯誤流。

2.5 識別修改 `final` 字段的代碼

通過深度反射修改 final 字段的代碼通常是庫代碼，而不是應用代碼。可以通過以下方式精確識別修改 final 字段的代碼：

使用上述方法啓動 Java 運行時，即 --illegal-final-field-mutation=debug。
使用 JDK Flight Recorder (JFR) 啓動 Java 運行時。當啓用 JFR 時，每當代碼修改 final 實例字段或使用 Lookup.unreflectSetter 獲取對反射 final 字段具有寫訪問權限的 MethodHandle 時，JVM會記錄一個 jdk.FinalFieldMutation 事件。此事件標識聲明 final 字段的類、final 字段的名稱以及堆棧跟蹤，以顯示 final 字段修改的來源。

例如，以下是如何創建 JFR 錄製並顯示 jdk.FinalFieldMutation 事件的方法：

$ java -XX:StartFlightRecording:filename=recording.jfr ...
$ jfr print --events jdk.FinalFieldMutation recording.jfr

3. 深度反射 API 的行為變更

在 JDK 26 中，深度反射 API 的行為發生了以下變化：

Field::setAccessible 的行為保持不變。當代碼對 Field 對象 f 調用 f.setAccessible(true) 時，代碼必須與 f 反映的字段位於同一個模塊中，或者如果代碼位於不同的模塊中，則 f 反映的字段必須通過導出或開放對調用者可訪問。如果這些條件不滿足，調用將拋出 InaccessibleObjectException。
Field::set 的行為在 JDK 26 中發生了變化。如果代碼對 Field 對象 f 調用 f.set(...)，並且 f 反映的字段是 final 的，則只有在滿足以下條件時才會修改字段：

已成功調用 f.setAccessible(true)；
字段的聲明類所在的包對調用者的模塊開放；
調用者的模塊已啓用 final 字段修改。
如果模塊未啓用 final 字段修改，且該模塊中的代碼嘗試通過深度反射修改任何 final 字段，則會拋出 IllegalAccessException，除非被 --illegal-final-field-mutation 抑制。

如果模塊已啓用 final 字段修改，且該模塊中的代碼嘗試通過深度反射修改某個包中的 final 字段，但該包未對模塊開放，則會拋出 IllegalAccessException，除非被 --illegal-final-field-mutation 抑制。

4. 相關方法的行為變更

MethodHandles.Lookup::unreflectSetter 的行為變更與 Field::set 相同。
Module::addOpens 方法允許模塊 M 中的調用者在運行時將模塊 N 中的包開放給另一個模塊 O，前提是該包已對 M 開放。如果模塊 M 和 N 均未在命令行上啓用 final 字段修改，則 JVM 將信任該包中的 final 字段。隨後，從 M 調用 addOpens 不會啓用 O 修改該包中的 final 字段。即使 O 在命令行上已啓用 final 字段修改，也是如此。
ModuleLayer.Controller::addOpens 和 Instrumentation::redefineModule 的行為與上述相同。
java.lang.System 類的 setIn、setOut 和 setErr 方法用於修改該類的 in、out 和 err 這些 final 字段。這些字段始終受到寫保護，這意味着只能通過調用相應的方法來修改它們，而不能通過深度反射來修改。在 JDK 26 中，這些字段及其相應方法沒有任何變化。

5. 序列化庫的替代方案

為了應對未來版本中加強的 final 字段限制，序列化庫將無法再直接使用深度反射來修改 final 字段。取而代之的是，序列化庫的維護者應使用 sun.reflect.ReflectionFactory API 來序列化和反序列化對象。此 API 允許序列化庫獲取一個方法句柄，該方法句柄指向特殊代碼，用於通過直接分配實例字段（包括 final 字段）的值來初始化對象。這種由 JDK 動態生成的代碼賦予了序列化庫與 JDK 自身序列化設施相同的權限，無需在序列化庫的模塊中啓用 final 字段修改。

sun.reflect.ReflectionFactory 類僅支持反序列化實現了 java.io.Serializable 接口的類的對象。這一限制平衡了使用序列化庫的開發者的利益與所有開發者對正確和高效執行的更廣泛利益。它確保了 JVM 在執行優化（如常量摺疊）時，不會過度限制其可以做出的假設：它必須假設可序列化對象中的 final 字段可能是可變的，但也可以假設所有其他對象中的 final 字段（佔大多數）是永久不可變的。

如果未啓用 final 字段修改，那麼 sun.reflect.ReflectionFactory 將是唯一能夠修改 final 字段的機制。如果 JVM 檢測到某個類的 ReflectionFactory API 返回的方法句柄不會修改 final 字段，那麼它可以將該類中的 final 字段視為永久不可變的。幸運的是，JVM 可能能夠對許多 JDK 類做到這一點。例如，實現不可修改列表的 JDK 類通過調用它們的構造函數來反序列化，而不是通過分配它們的實例字段。對於這些類，ReflectionFactory 代碼可以委託給類的反序列化方法，從而避免修改 final 字段。瞭解這一點後，JVM 可以信任每個不可修改列表的 final 字段，即使這些列表是由第三方庫反序列化的。

6. 對其他庫和框架的建議

一些依賴注入、單元測試和模擬框架等庫使用深度反射來操作對象，包括修改 final 字段。這些組件的維護者應儘量避免要求用户啓用 final 字段修改，而是尋找避免修改 final 字段或訪問私有字段的架構方法。例如，大多數依賴注入框架現在禁止注入 final 字段，所有框架都建議使用構造函數注入，而不是字段注入。

7. 克隆方法的實現建議

帶有 final 字段的類的作者在實現 clone 方法時一直面臨挑戰。如果 clone 方法的實現調用了 super.clone()，則它無法僅通過賦值來定製返回對象中的 final 字段的值。有時，clone 方法的實現會使用深度反射來修改這些字段，但這在未來的 JDK 版本中將不再可行，因為默認情況下不允許修改 final 字段。

Joshua Bloch 在 2001 年出版的《Effective Java》一書中建議避免使用 clone，並聲明靜態工廠方法（第 11 條：“謹慎覆蓋 clone()”）。在必須繼續實現 clone 的類中，應將 super.clone() 替換為通過（可能是非公共的）構造函數實例化類的代碼。因為構造函數可以將 final 字段初始化為所需的值，所以 clone 方法無需使用深度反射。

8. 從本地代碼修改 `final` 字段

本地代碼可以通過調用 Java 原生接口（JNI）中定義的 Set<type>Field 函數或 SetStatic<type>Field 函數來修改 Java 字段。

對 final 字段調用這些函數的結果是未定義行為。這意味着 Java 構建程序的構建塊，如對象、數組和類型，不再具有完整性。JVM 無法保證它們的行為符合其規範；例如，程序可能會在 JVM 不拋出異常的情況下訪問數組邊界之外的元素，從而導致內存損壞或進程崩潰。隨着我們增強 JVM 的優化目錄，這些優化利用了對 Java 代碼施加的 final 字段限制，由於本地代碼中未定義行為導致的奇怪結果的可能性變得越來越大。

由於已經存在由於未定義行為的可能性而對執行本地代碼的限制，因此默認情況下 JVM 可以假設不會調用這些函數。然而，如果啓用了本地訪問，那麼我們建議啓用新的診斷功能，以減輕由於通過 JNI 修改 final 字段而導致的奇怪結果的風險：

如果使用啓用了本地代碼統一日誌記錄的應用程序啓動（-Xlog:jni=debug），則對 final 字段調用上述 JNI 函數中的任何一個都會導致記錄一條消息：

[0.20s][debug][jni] Set<type>Field of final instance field C.f

或者

[0.20s][debug][jni] SetStatic<type>Field of final static field C.f

如果使用啓用了 JNI 函數額外檢查的應用程序啓動（-Xcheck:jni），則對 final 字段調用上述 JNI 函數中的任何一個都會導致打印一條警告。
在未來版本的 JDK 中，我們可能會更改上述 JNI 函數，以便在對 final 字段調用時始終成功返回，但實際上不會進行任何修改。

對於通過 sun.misc.Unsafe API 修改 final 字段的 Java 代碼，沒有診斷功能。這種修改可能會違反完整性，並可能導致奇怪的錯誤或 JVM 崩潰。從 JDK 24 開始，我們已經開始移除 sun.misc.Unsafe 中可以用來修改 final 字段的方法。

9. 風險與假設

自 JDK 5 以來，Java 平台一直允許修改 final 字段，因此存在現有應用可能受到提議的 final 字段限制影響的風險。我們假設那些直接或間接依賴 final 字段修改的應用開發者能夠通過 --enable-final-field-mutation 配置 Java 運行時來啓用該功能，這與他們已經可以通過 --add-opens 配置 Java 運行時以禁用模塊的強封裝類似。

10. 替代方案

10.1 依賴推測優化

而不是強制 final 字段的不可變性，Java 運行時可以依賴推測：它可以樂觀地假設 final 字段沒有被修改，檢測到修改發生時，再根據需要對代碼進行去優化。

儘管推測性優化是 JVM 的 JIT 編譯器的常用手段，但在這種情況下可能不夠用。未來的計劃優化可能不僅依賴於進程生命週期內的不可變性，還依賴於從一次應用運行到下一次的字段不可變性。

10.2 指定允許被修改的模塊

而不是指定哪些模塊的代碼可以修改 final 字段，我們可以要求開發者指定哪些模塊允許其 final 字段被修改。

修改 final 字段是不受歡迎的，因此最好在命令行上記錄哪些模塊的代碼應該被更新，以不再嘗試修改字段。相反，指定哪些模塊的 final 字段可以被修改，不會記錄它們為什麼允許字段被修改，也不會鼓勵庫遷移到不修改那些字段。

10.3 指定修改和被修改的模塊

我們可以要求 --enable-final-field-mutation 指定執行修改的模塊以及包含被修改字段的模塊。

這將是不必要的負擔。在許多實際情況下，--enable-final-field-mutation 將與 --add-opens 一起指定，後者已經指定了深度反射的雙方。

11. 總結

JEP 500 的實施，將讓 final 字段真正不可變，提升 Java 程序的安全性和性能。雖然這一變化可能會對一些依賴反射修改 final 字段的代碼產生影響，但通過合理的配置和調整，我們可以順利過渡到新的時代。讓我們一起期待一個更安全、更高效的 Java 生態系統吧！

12. 致謝

感謝您閲讀到這裏！如果您覺得這篇文章對您有所幫助或啓發，希望您能給我一個小小的鼓勵：

點贊：您的點贊是我繼續創作的動力，讓我知道這篇文章對您有價值！
關注：關注我，您將獲得更多精彩內容和最新更新，讓我們一起探索更多知識！
收藏：方便您日後回顧，也可以隨時找到這篇文章，再次閲讀或參考。
轉發：如果您認為這篇文章對您的朋友或同行也有幫助，歡迎轉發分享，讓更多人受益！

您的每一個支持都是我不斷進步的動力，非常感謝您的陪伴和支持！如果您有任何疑問或想法，也歡迎在評論區留言，我們一起交流！

mizeyar 博客

mizeyar 博客

博客 / 詳情