Java Final與Effectively Final

1. 介紹

Java 8 引入的眾多功能中，其中一個最有趣的功能是 effectively final。即不用 final 修飾符也能達到同樣的效果。

本文將介紹該功能的起源以及編譯器處理 effectively final 與 final 關鍵字的不同之處。此外，還會通過一個 effectively final 變量的問題案例給出解決方案。

2. Effectively Final 的起源

簡而言之，如果對象或基礎類型的變量在初始化后值不發生改變，則可以把它們看做 effectively final。只要不改變對象引用，即使引用的對象發生狀態改變，該對象也是 effectively final。

在 Java 引入該功能之前，不能在匿名類中使用非 final 局部變量。此外，也不能在匿名類、內部類和 lambda 表達式中多次賦值。新功能的加入節省了為 effectively final 變量輸入 final 關鍵字的工作。

匿名類是一種內部類，不能訪問非 final 變量或 effectively final 變量，也無法按照 JLS 8.1.3 的規定在其封閉作用域內的變量進行修改。lambda 表達式也有類似的限制，修改變量可能會帶來并發問題。

docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.1.3

3. Final vs Effectively Final

要確認一個 final 變量是不是 effectively final，最簡單的辦法就是刪除 final 關鍵字看能否編譯并運行：

重新賦值或者改變 effectively final 都會報告無效代碼。

3.1 編譯器處理

JLS 4.12.4 指出，從方法參數或局部變量中刪除 final 修飾符且不產生編譯錯誤，則該變量為 effectively final。在程序中為變量聲明加上 final 關鍵字，那么該變量也會變成 effectively final。

docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.12

與 final 變量不同，Java 編譯器不會對 effectively final 變量進行額外優化。

下面這個簡單的示例中聲明兩個 final String 變量，僅用作字符串連接：

編譯器會將上面 main 方法實際執行的代碼變成下面這樣：

去掉 final 關鍵字，這些變量將被視為 effectively final。但編譯器不會因為它們僅用作字符串連接而對它們優化。

4. 原子操作

在 lambda 表達式和匿名類中修改變量不是一個好習慣。因為我們不知道這些變量在方法塊中會如何使用，在多線程環境中修改也可能會得到意外的結果。

關于使用 lambda 表達式的最佳實踐已經有了一個教程，另外還有一個教程關于修改lambda 表達式中常見的反模式。有一種替代方案可以在這種場景中修改變量，通過原子性實現線程安全。

java.util.concurrent.atomic 提供了像 AtomicReference 和 AtomicInteger 這樣的類?？梢允褂迷硬僮餍薷?lambda 表達式中的變量：

5. 總結

本文介紹了 final 變量和 effectively final 變量的區別，并且介紹了一種安全修改 lambda 函數變量的方案。