Java編碼技巧之高效代碼50例

導讀

世界上只有兩種物質：高效率和低效率；世界上只有兩種人：高效率的人和低效率的人。——蕭伯納

同理，世界上只有兩種代碼：高效代碼和低效代碼；世界上只有兩種人：編寫高效代碼的人和編寫低效代碼的人。如何編寫高效代碼，是每一個研發團隊都面臨的一個重大問題。因此，做者根據實際經驗，查閱了大量資料，總結了"Java高效代碼50例"，讓每個Java程序員都能編寫出"高效代碼"。

1.常量&變量

1.1.直接賦值常量值，禁止聲明新對象

直接賦值常量值，只是建立了一個對象引用，而這個對象引用指向常量值。

反例：

正例：

1.2.當成員變量值無需改變時，儘可能定義爲靜態常量

在類的每一個對象實例中，每一個成員變量都有一份副本，而成員靜態常量只有一份實例。

反例：

正例：

1.3.儘可能使用基本數據類型，避免自動裝箱和拆箱

Java 中的基本數據類型double、float、long、int、short、char、boolean，分別對應包裝類Double、Float、Long、Integer、Short、Character、Boolean。 JVM支持基本類型與對應包裝類的自動轉換，被稱爲自動裝箱和拆箱。裝箱和拆箱都是須要CPU和內存資源的，因此應儘可能避免使用自動裝箱和拆箱。

反例：

正例：

1.4.若是變量的初值會被覆蓋，就沒有必要給變量賦初值

反例：

正例：

1.5.儘可能使用函數內的基本類型臨時變量

在函數內，基本類型的參數和臨時變量都保存在棧（Stack）中，訪問速度較快；對象類型的參數和臨時變量的引用都保存在棧（Stack）中，內容都保存在堆（Heap）中，訪問速度較慢。在類中，任何類型的成員變量都保存在堆（Heap）中，訪問速度較慢。

反例：

正例：

1.6.儘可能不要在循環體外定義變量

在老版JDK中，建議「儘可能不要在循環體內定義變量」，可是在新版的JDK中已經作了優化。經過對編譯後的字節碼分析，變量定義在循環體外和循環體內沒有本質的區別，運行效率基本上是同樣的。反而，根據「 局部變量做用域最小化 」原則，變量定義在循環體內更科學更便於維護，避免了延長大對象生命週期致使延緩回收問題 。

反例：

正例：

1.7.不可變的靜態常量，儘可能使用非線程安全類

不可變的靜態常量，雖然須要支持多線程訪問，也可使用非線程安全類。

反例：

正例：

1.8.不可變的成員變量，儘可能使用非線程安全類

不可變的成員變量，雖然須要支持多線程訪問，也可使用非線程安全類。

反例：

正例：

2.對象&類

2.1.禁止使用JSON轉化對象

JSON提供把對象轉化爲JSON字符串、把JSON字符串轉爲對象的功能，因而被某些人用來轉化對象。這種對象轉化方式，雖然在功能上沒有問題，可是在性能上卻存在問題。

反例：

正例：

2.2.儘可能不使用反射賦值對象

用反射賦值對象，主要優勢是節省了代碼量，主要缺點倒是性能有所降低。

反例：

正例：

2.3.採用Lambda表達式替換內部匿名類

對於大多數剛接觸JDK8的同窗來講，都會認爲Lambda表達式就是匿名內部類的語法糖。實際上， Lambda表達式在大多數虛擬機中採用invokeDynamic指令實現，相對於匿名內部類在效率上會更高一些。

反例：

正例：

2.4.儘可能避免定義沒必要要的子類

多一個類就須要多一份類加載，因此儘可能避免定義沒必要要的子類。

反例：

正例：

2.5.儘可能指定類的final修飾符

爲類指定final修飾符，可讓該類不能夠被繼承。若是指定了一個類爲final，則該類全部的方法都是final的，Java編譯器會尋找機會內聯全部的final方法。內聯對於提高Java運行效率做用重大，具體可參見Java運行期優化，可以使性能平均提升50%。

反例：

正例：

注意：使用Spring的AOP特性時，須要對Bean進行動態代理，若是Bean類添加了final修飾，會致使異常。

3.方法

3.1.把跟類成員變量無關的方法聲明成靜態方法

靜態方法的好處就是不用生成類的實例就能夠直接調用。靜態方法再也不屬於某個對象，而是屬於它所在的類。只須要經過其類名就能夠訪問，不須要再消耗資源去反覆建立對象。即使在類內部的私有方法，若是沒有使用到類成員變量，也應該聲明爲靜態方法。

反例：

正例：

3.2.儘可能使用基本數據類型做爲方法參數類型，避免沒必要要的裝箱、拆箱和空指針判斷

反例：

正例：

3.3.儘可能使用基本數據類型做爲方法返回值類型，避免沒必要要的裝箱、拆箱和空指針判斷

在JDK類庫的方法中，不少方法返回值都採用了基本數據類型，首先是爲了不沒必要要的裝箱和拆箱，其次是爲了不返回值的空指針判斷。好比：Collection.isEmpty()和Map.size()。

反例：

正例：

3.4.協議方法參數值非空，避免沒必要要的空指針判斷

協議編程，能夠@NonNull和@Nullable標註參數，是否遵循全憑調用者自覺。

反例：

正例：

3.5.協議方法返回值非空，避免沒必要要的空指針判斷

協議編程，能夠@NonNull和@Nullable標註參數，是否遵循全憑實現者自覺。

反例：

正例：

3.6.被調用方法已支持判空處理，調用方法無需再進行判空處理

反例：

正例：

3.7.儘可能避免沒必要要的函數封裝

方法調用會引發入棧和出棧，致使消耗更多的CPU和內存，應當儘可能避免沒必要要的函數封裝。固然，爲了使代碼更簡潔、更清晰、更易維護，增長必定的方法調用所帶來的性能損耗是值得的。

反例：

正例：

3.8.儘可能指定方法的final修飾符

方法指定final修飾符，可讓方法不能夠被重寫，Java編譯器會尋找機會內聯全部的final方法。內聯對於提高Java運行效率做用重大，具體可參見Java運行期優化，可以使性能平均提升50%。

注意：全部的private方法會隱式地被指定final修飾符，因此無須再爲其指定final修飾符。

反例：

正例：

注意：使用Spring的AOP特性時，須要對Bean進行動態代理，若是方法添加了final修飾，將不會被代理。

4.表達式

4.1.儘可能減小方法的重複調用

反例：

正例：

4.2.儘可能避免沒必要要的方法調用

反例：

正例：

4.3.儘可能使用移位來代替正整數乘除

用移位操做能夠極大地提升性能。對於乘除2^n(n爲正整數)的正整數計算，能夠用移位操做來代替。

反例：

正例：

4.4.提取公共表達式，避免重複計算

提取公共表達式，只計算一次值，而後重複利用值。

反例：

正例：

4.5.儘可能不在條件表達式中用!取反

使用!取反會多一次計算，若是沒有必要則優化掉。

反例：

正例：

4.6.對於多常量選擇分支，儘可能使用switch語句而不是if-else語句

if-else語句，每一個if條件語句都要加裝計算，直到if條件語句爲true爲止。switch語句進行了跳轉優化，Java中採用tableswitch或lookupswitch指令實現，對於多常量選擇分支處理效率更高。通過試驗證實：在每一個分支出現機率相同的狀況下，低於5個分支時if-else語句效率更高，高於5個分支時switch語句效率更高。

反例：

正例：

備註：若是業務複雜，能夠採用Map實現策略模式。

5.字符串

5.1.儘可能不要使用正則表達式匹配

正則表達式匹配效率較低，儘可能使用字符串匹配操做。

反例：

正例：

5.2.儘可能使用字符替換字符串

字符串的長度不肯定，而字符的長度固定爲1，查找和匹配的效率天然提升了。

反例：

正例：

5.3.儘可能使用StringBuilder進行字符串拼接

String是final類，內容不可修改，因此每次字符串拼接都會生成一個新對象。StringBuilder在初始化時申請了一塊內存，之後的字符串拼接都在這塊內存中執行，不會申請新內存和生成新對象。

反例：

正例：

5.4.不要使用""+轉化字符串

使用""+進行字符串轉化，使用方便可是效率低，建議使用String.valueOf.

反例：

正例：

6.數組

6.1.不要使用循環拷貝數組，儘可能使用System.arraycopy拷貝數組

推薦使用System.arraycopy拷貝數組，也可使用Arrays.copyOf拷貝數組。

反例：

正例：

6.2.集合轉化爲類型T數組時，儘可能傳入空數組T[0]

將集合轉換爲數組有2種形式：toArray(new T[n])和toArray(new T[0])。在舊的Java版本中，建議使用toArray(new T[n])，由於建立數組時所需的反射調用很是慢。在OpenJDK6後，反射調用是內在的，使得性能得以提升，toArray(new T[0])比toArray(new T[n])效率更高。此外，toArray(new T[n])比toArray(new T[0])多獲取一次列表大小，若是計算列表大小耗時過長，也會致使toArray(new T[n])效率下降。

反例：

正例：

建議：集合應該提供一個toArray(Class<T> clazz)方法，避免無用的空數組初始化（new T[0]）。

6.3.集合轉化爲Object數組時，儘可能使用toArray()方法

轉化Object數組時，沒有必要使用toArray[new Object[0]]，能夠直接使用toArray()。避免了類型的判斷，也避免了空數組的申請，因此效率會更高。

反例：

正例：

7.集合

7.1.初始化集合時，儘可能指定集合大小

Java集合初始化時都會指定一個默認大小，當默認大小再也不知足數據需求時就會擴容，每次擴容的時間複雜度有多是O(n)。因此，儘可能指定預知的集合大小，就能避免或減小集合的擴容次數。

反例：

正例：

7.2.不要使用循環拷貝集合，儘可能使用JDK提供的方法拷貝集合

JDK提供的方法能夠一步指定集合的容量，避免屢次擴容浪費時間和空間。同時，這些方法的底層也是調用System.arraycopy方法實現，進行數據的批量拷貝效率更高。

反例：

正例：

7.3.儘可能使用Arrays.asList轉化數組爲列表

原理與"不要使用循環拷貝集合，儘可能使用JDK提供的方法拷貝集合"相似。

反例：

正例：

7.4.直接迭代須要使用的集合

直接迭代須要使用的集合，無需經過其它操做獲取數據。

反例：

正例：

7.5.不要使用size方法檢測空，必須使用isEmpty方法檢測空

使用size方法來檢測空邏輯上沒有問題，但使用isEmpty方法使得代碼更易讀，而且能夠得到更好的性能。任何isEmpty方法實現的時間複雜度都是O(1)，可是某些size方法實現的時間複雜度有多是O(n)。

反例：

正例：

7.6.非隨機訪問的List，儘可能使用迭代代替隨機訪問

對於列表，可分爲隨機訪問和非隨機訪問兩類，能夠用是否實現RandomAccess接口判斷。隨機訪問列表，直接經過get獲取數據不影響效率。而非隨機訪問列表，經過get獲取數據效率極低。

反例：

正例：

其實，無論列表支不支持隨機訪問，都應該使用迭代進行遍歷。

7.7.儘可能使用HashSet判斷值存在

在Java集合類庫中，List的contains方法廣泛時間複雜度是O(n)，而HashSet的時間複雜度爲O(1)。若是須要頻繁調用contains方法查找數據，能夠先將List轉換成HashSet。

反例：

正例：

7.8.避免先判斷存在再進行獲取

若是須要先判斷存在再進行獲取，能夠直接獲取並判斷空，從而避免了二次查找操做。

反例：

正例：

8.異常

8.1.直接捕獲對應的異常

直接捕獲對應的異常，避免用instanceof判斷，效率更高代碼更簡潔。

反例：

正例：

8.2.儘可能避免在循環中捕獲異常

當循環體拋出異常後，無需循環繼續執行時，沒有必要在循環體中捕獲異常。由於，過多的捕獲異常會下降程序執行效率。

反例：

正例：

8.3.禁止使用異常控制業務流程

相對於條件表達式，異常的處理效率更低。

反例：

正例：

9.緩衝區

9.1.初始化時儘可能指定緩衝區大小

初始化時，指定緩衝區的預期容量大小，避免屢次擴容浪費時間和空間。

反例：

正例：

9.2.儘可能重複使用同一緩衝區

針對緩衝區，Java虛擬機須要花時間生成對象，還要花時間進行垃圾回收處理。因此，儘可能重複利用緩衝區。

反例：

正例：

其中，使用setLength方法讓緩衝區從新從0開始。

9.3.儘可能設計使用同一緩衝區

爲了提升程序運行效率，在設計上儘可能使用同一緩衝區。

反例：

正例：

去掉每一個轉化方法中的緩衝區申請，申請一個緩衝區給每一個轉化方法使用。從時間上來講，節約了大量緩衝區的申請釋放時間；從空間上來講，節約了大量緩衝區的臨時存儲空間。

9.4.儘可能使用緩衝流減小IO操做

使用緩衝流BufferedReader、BufferedWriter、BufferedInputStream、BufferedOutputStream等，能夠大幅減小IO次數並提高IO速度。

反例：

正例：

其中，能夠根據實際狀況手動指定緩衝流的大小，把緩衝流的緩衝做用發揮到最大。

10.線程

10.1.在單線程中，儘可能使用非線程安全類

使用非線程安全類，避免了沒必要要的同步開銷。

反例：

正例：

10.2.在多線程中，儘可能使用線程安全類

使用線程安全類，比本身實現的同步代碼更簡潔更高效。

反例：

正例：

10.3.儘可能減小同步代碼塊範圍

在一個方法中，可能只有一小部分的邏輯是須要同步控制的，若是同步控制了整個方法會影響執行效率。因此，儘可能減小同步代碼塊的範圍，只對須要進行同步的代碼進行同步。

反例：

正例：

10.4.儘可能合併爲同一同步代碼塊

同步代碼塊是有性能開銷的，若是肯定能夠合併爲同一同步代碼塊，就應該儘可能合併爲同一同步代碼塊。

反例：

正例：

10.5.儘可能使用線程池減小線程開銷

多線程中兩個必要的開銷：線程的建立和上下文切換。採用線程池，能夠儘可能地避免這些開銷。

反例：

正例：

後記

做爲一名長期奮戰在業務一線的"IT民工"，沒有機會去研究什麼高深莫測的"理論"，只能專一於眼前看得見摸得着的"技術"，致力於作到"幹一行、愛一行、專注行、精一行"。

本文是《 Java編程技巧之數據結構 》的姊妹篇，做者在這裏只是拋磚引玉，但願你們進行補充完善。

---

本文做者：中間件小哥

原文連接

本文爲阿里雲內容，未經容許不得轉載。