1.讓代碼性能更高
1.1.需要 Map 的主鍵和取值時，應該迭代 entrySet()
當循環中只需要 Map 的主鍵時，迭代 keySet() 是正確的。但是，當需要主鍵和取值時，迭代 entrySet() 纔是更高效的做法，比先迭代 keySet() 後再去 get 取值性能更佳。
反例：
正例：
1.2.應該使用 Collection.isEmpty() 檢測空
使用 Collection.size() 來檢測空邏輯上沒有問題，但是使用 Collection.isEmpty() 使得代碼更易讀，並且可以獲得更好的性能。任何 Collection.isEmpty() 實現的時間複雜度都是 O(1) ，但是某些 Collection.size() 實現的時間複雜度可能是O(n)。
反例：
正例：
如果需要還需要檢測 null ，可採用：
-
CollectionUtils.isEmpty(collection)
-
CollectionUtils.isNotEmpty(collection)
1.3.不要把集合對象傳給自己
將集合作爲參數傳遞給集合自己的方法要麼是一個錯誤，要麼是無意義的代碼。
此外，由於某些方法要求參數在執行期間保持不變，因此將集合傳遞給自身可能會導致異常行爲。
反例：
1.4.集合初始化儘量指定大小
java 的集合類用起來十分方便，但是看源碼可知，集合也是有大小限制的。每次擴容的時間複雜度很有可能是 O(n) ，所以儘量指定可預知的集合大小，能減少集合的擴容次數。
反例：
正例：
1.5.字符串拼接使用 StringBuilder
一般的字符串拼接在編譯期 java 會進行優化，但是在循環中字符串拼接，java 編譯期無法做到優化，所以需要使用 StringBuilder 進行替換。
反例：
正例：
1.6.List的隨機訪問
大家都知道數組和鏈表的區別：數組的隨機訪問效率更高。當調用方法獲取到 List 後，如果想隨機訪問其中的數據，並不知道該數組內部實現是鏈表還是數組，怎麼辦呢？可以判斷它是否實現 RandomAccess 接口。
正例：
1.7.頻繁調用 Collection.contains 方法請使用 Set
在 java 集合類庫中，List 的 contains 方法普遍時間複雜度是 O(n) ，如果在代碼中需要頻繁調用 contains 方法查找數據，可以先將 list 轉換成 HashSet 實現，將 O(n) 的時間複雜度降爲 O(1) 。
反例：
正例：
2.讓代碼更優雅
2.1.長整型常量後添加大寫 L
在使用長整型常量值時，後面需要添加 L ，必須是大寫的 L ，不能是小寫的 l ，小寫 l 容易跟數字 1 混淆而造成誤解。
反例：
正例：
2.2.不要使用魔法值
當你編寫一段代碼時，使用魔法值可能看起來很明確，但在調試時它們卻不顯得那麼明確了。這就是爲什麼需要把魔法值定義爲可讀取常量的原因。但是，-1、0 和 1 不被視爲魔法值。
反例：
正例：
2.3.不要使用集合實現來賦值靜態成員變量
對於集合類型的靜態成員變量，不要使用集合實現來賦值，應該使用靜態代碼塊賦值。
反例：
正例：
2.4.建議使用 try-with-resources 語句
Java 7 中引入了 try-with-resources 語句，該語句能保證將相關資源關閉，優於原來的 try-catch-finally 語句，並且使程序代碼更安全更簡潔。
反例：
正例：
2.5.刪除未使用的私有方法和字段
刪除未使用的私有方法和字段，使代碼更簡潔更易維護。若有需要再使用，可以從歷史提交中找回。
反例：
正例：
2.6.刪除未使用的局部變量
刪除未使用的局部變量，使代碼更簡潔更易維護。
反例：
正例：
2.7.刪除未使用的方法參數
未使用的方法參數具有誤導性，刪除未使用的方法參數，使代碼更簡潔更易維護。但是，由於重寫方法是基於父類或接口的方法定義，即便有未使用的方法參數，也是不能刪除的。
反例：
正例：
2.8.刪除表達式的多餘括號
對應表達式中的多餘括號，有人認爲有助於代碼閱讀，也有人認爲完全沒有必要。對於一個熟悉 Java 語法的人來說，表達式中的多餘括號反而會讓代碼顯得更繁瑣。
反例：
正例：
2.9.工具類應該屏蔽構造函數
工具類是一堆靜態字段和函數的集合，不應該被實例化。但是， Java 爲每個沒有明確定義構造函數的類添加了一個隱式公有構造函數。所以，爲了避免 java "小白"使用有誤，應該顯式定義私有構造函數來屏蔽這個隱式公有構造函數。
反例：
正例：
2.10.刪除多餘的異常捕獲並拋出
用catch語句捕獲異常後，什麼也不進行處理，就讓異常重新拋出，這跟不捕獲異常的效果一樣，可以刪除這塊代碼或添加別的處理。
反例：
正例：
2.11.公有靜態常量應該通過類訪問
雖然通過類的實例訪問公有靜態常量是允許的，但是容易讓人它誤認爲每個類的實例都有一個公有靜態常量。所以，公有靜態常量應該直接通過類訪問。
反例：
正例：
2.12.不要用 NullPointerException 判斷空
空指針異常應該用代碼規避（比如檢測不爲空），而不是用捕獲異常的方式處理。
反例：
正例：
2.13.使用 String.valueOf(value) 代替 ""+value
當要把其它對象或類型轉化爲字符串時，使用 String.valueOf(value) 比 ""+value 的效率更高。
反例：
正例：
2.14.過時代碼添加 @Deprecated 註解
當一段代碼過時，但爲了兼容又無法直接刪除，不希望以後有人再使用它時，可以添加 @Deprecated 註解進行標記。在文檔註釋中添加 @deprecated 來進行解釋，並提供可替代方案
正例：
3.讓代碼遠離 bug
3.1.禁止使用構造方法 BigDecimal(double)
BigDecimal(double) 存在精度損失風險，在精確計算或值比較的場景中可能會導致業務邏輯異常。
反例：
正例：
3.2.返回空數組和空集合而不是 null
返回 null ，需要調用方強制檢測 null ，否則就會拋出空指針異常。返回空數組或空集合，有效地避免了調用方因爲未檢測 null 而拋出空指針異常，還可以刪除調用方檢測 null 的語句使代碼更簡潔。
反例：
正例：
3.3.優先使用常量或確定值來調用 equals 方法
對象的 equals 方法容易拋空指針異常，應使用常量或確定有值的對象來調用 equals 方法。當然，使用java.util.Objects.equals() 方法是最佳實踐。
反例：
正例：
3.4.枚舉的屬性字段必須是私有不可變
枚舉通常被當做常量使用，如果枚舉中存在公共屬性字段或設置字段方法，那麼這些枚舉常量的屬性很容易被修改。理想情況下，枚舉中的屬性字段是私有的，並在私有構造函數中賦值，沒有對應的 Setter 方法，最好加上 final 修飾符。
反例：
正例：
3.5.小心 String.split(String regex)
字符串 String 的 split 方法，傳入的分隔字符串是正則表達式！部分關鍵字（比如.[]()\|等）需要轉義
反例：
正例：
總結
這篇文章，可以說是從事 Java 開發的經驗總結，分享出來以供大家參考。希望能幫大家避免踩坑，讓代碼更加高效優雅。
作者：中間件小哥