可以將變量聲明為final。 最終變量只能分配一次。 如果分配了最終變量，則將導(dǎo)致編譯時錯誤，除非在分配前立即將其絕對取消分配。

分配任何最終變量后，將永遠(yuǎn)無法對其進行更改。 如果變量引用任何對象的任何實例，它將繼續(xù)引用相同的對象實例，但是可以修改對象的內(nèi)部狀態(tài)。

有效地最終

且僅當(dāng)且僅當(dāng)變量才可以被視為有效的最終變量

它不是最終的

分配發(fā)生一次

我發(fā)現(xiàn)有效地解釋final的最簡單方法是想象將final修飾符添加到變量聲明中。 如果通過此更改，程序在編譯時和運行時都繼續(xù)以相同的方式運行，則該變量實際上是最終變量。

在Lamda表達式中使用

使用但未在lambda表達式中聲明的任何局部變量，形式參數(shù)或異常參數(shù)必須聲明為final或有效地為final，否則在嘗試使用時會發(fā)生編譯時錯誤。

將局部變量捕獲限制為有效的不變變量的目的是使開發(fā)人員將注意力轉(zhuǎn)移到更容易并行化的，自然線程安全的技術(shù)上。 如果管理不當(dāng)，可變字段始終是潛在的并發(fā)問題來源。 禁止通過lambda表達式捕獲字段將降低實用性，而無需執(zhí)行任何操作。

最終關(guān)鍵字的使用

根據(jù)我的觀點，最好在適當(dāng)?shù)臅r候?qū)⒕植孔兞?#xff0c;方法參數(shù)，字段變量標(biāo)記為final。 它警告其他開發(fā)人員不要意外修改值。 除此之外，它還向編譯器發(fā)出信號以優(yōu)化類文件。 有很多反對此說法的說法，即在源文件中使用final關(guān)鍵字不能優(yōu)化類文件是不正確的。 我強烈建議您看一下Robert Simons Jr編寫的Hardcore Java ，其中詳細(xì)介紹了final關(guān)鍵字的使用及其優(yōu)化。

我覺得使用final關(guān)鍵字會使任何開發(fā)人員都清楚代碼的意圖。 將變量設(shè)為final可以減輕程序員的負(fù)擔(dān)，使他們可以遍歷代碼以查看變量在初始化后是否已更改。 就在多線程環(huán)境中維護狀態(tài)而言，它也比非最終變量安全得多。

根據(jù)RustyX在StackOverflow 線程中提供的詳細(xì)基準(zhǔn)測試，以下程序演示了明顯的性能提升：

public class FinalTest {public static final int N_ITERATIONS = 10_00_000;public static String testFinal() {final String a = "a";final String b = "b";return a + b;}public static String testNonFinal() {String a = "a";String b = "b";return a + b;}public static void main(String[] args) {long tStart, tElapsed;tStart = System.currentTimeMillis();for (int i = 0; i < N_ITERATIONS; i++)testFinal();tElapsed = System.currentTimeMillis() - tStart;System.out.println("Method with finals took " + tElapsed + " ms");tStart = System.currentTimeMillis();for (int i = 0; i < N_ITERATIONS; i++)testNonFinal();tElapsed = System.currentTimeMillis() - tStart;System.out.println("Method without finals took " + tElapsed + " ms");}}

結(jié)果非常出色：

Method with finals took 5 ms Method without finals took 273 ms

我個人也更傾向于使用不可變的類，并使用final關(guān)鍵字作為實例變量來表明這一點。 根據(jù)有效Java的 Joshua Bloch的說法，

不可變的類比可變的類更容易設(shè)計，實現(xiàn)和使用。 它們不易出錯，并且更安全。。此外，不可變對象可以恰好處于一種狀態(tài)，即創(chuàng)建該對象的狀態(tài)。 vs可變對象可以具有任意復(fù)雜的狀態(tài)空間。

靜態(tài)代碼分析工具

適當(dāng)時，像PMD這樣的靜態(tài)分析工具是使用final關(guān)鍵字的最大支持者之一。 有關(guān)更多信息，請查看此 。 如果缺少final關(guān)鍵字，則將FindBugs和CheckStyle配置為對變量發(fā)出警告。 我發(fā)現(xiàn)此鏈接支持在Checkstyle中使用final關(guān)鍵字：

在執(zhí)行該方法的算法期間更改參數(shù)的值可能會造成混淆，應(yīng)該避免。 讓Java編譯器阻止這種編碼樣式的一種好方法是將參數(shù)聲明為final。

Eclipse保存動作

Eclipse IDE提供了有用的“ 保存操作首選項”頁面 ，該頁面使您可以應(yīng)用主要側(cè)重于優(yōu)化源代碼的更改。 保存操作之一是在適當(dāng)?shù)那闆r下將最終關(guān)鍵字應(yīng)用于變量。

結(jié)論

在清晰的設(shè)計和可讀性方面，我支持在源文件中使用final關(guān)鍵字，而我的其他Java開發(fā)人員中很少有人因為它帶來的視覺混亂而與我不同意。 我同意，在局部變量，實例變量，方法參數(shù)，構(gòu)造函數(shù)參數(shù)，catch子句中使用final關(guān)鍵字似乎可以增加視覺混亂和冗長。 但是，如果有什么可以幫助任何未來的開發(fā)人員或維護人員更快，更可靠，更有效地執(zhí)行其工作的，我們應(yīng)該加以利用。

但是，當(dāng)然，這全都是個人喜好；-)我很想聽聽您對此的看法。

翻譯自: https://www.javacodegeeks.com/2017/07/all-about-finals.html

總結(jié)

以上是生活随笔為你收集整理的关于总决赛的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。