Java 的這些坑，你踩到了嗎？

前言

中國有句老話叫"事不過三"，指一個人犯了同樣的錯誤，一次兩次還可以原諒，再多就不可原諒了。寫代碼也是如此，同一個代碼“坑”，踩第一次叫"長了經驗"，踩第二次叫"加深印象"，踩第三次叫"不長記性"，踩三次以上就叫"不可救藥"。在本文中，筆者總結了一些 Java 坑，描述了問題現象，進行了問題分析，給出了避坑方法。希望大家在日常工作中，遇到了這類 Java 坑，能夠提前避讓開來。

1 對象比較方法

JDK 1.7 提供的 Objects.equals 方法，非常方便地實現了對象的比較，有效地避免了繁瑣的空指針檢查。

問題現象

在 JDK1.7 之前，在判斷一個短整型、整型、長整型包裝數據類型與常量是否相等時，我們一般這樣寫：

從 JDK1.7 之後，提供了 Objects.equals 方法，並推薦使用函數式編程，更改代碼如下：

為什麼直接把 == 替換為 Objects.equals 方法就會導致輸出結果不一樣？

問題分析

通過反編譯第一段代碼，我們得到語句 System.out.println(shortValue == 12345); 的字節碼指令如下：

原來，編譯器會判斷包裝數據類型對應的基本數據類型，並採用這個基本數據類型的指令進行比較（比如上面字節碼指令中的 sipush 和 if_icmpne 等），相當於編譯器自動對常量進行了數據類型的強制轉化。

為什麼採用 Objects.equals 方法後，編譯器不自動對常量進行數據類型的強制轉化？通過反編譯第二段代碼，我們得到語句 System.out.println(Objects.equals(shortValue, 12345)); 的字節碼指令如下：

invokestatic java.util.Objects.equals(java.lang.Object, java.lang.Object) : boolean [33]

原來，編譯器根據字面意思，認為常量 12345 默認基本數據類型是 int，所以會自動轉化為包裝數據類型 Integer。

通過分析Objects.equals方法的源代碼可知：語句 System.out.println(Objects.equals(shortValue, 12345))，因為 Objects.equals 的兩個參數對象類型不一致，一個是包裝數據類型 Short，另一個是包裝數據類型 Integer，所以最終的比較結果必然是false；而語句 System.out.println(Objects.equals(intValue, 12345))，因為 Objects.equals 的兩個參數對象類型一致，都是包裝數據類型 Integer 且取值相同，所以最終的比較結果必然是 true。

避坑方法

1）保持良好的編碼習慣，避免數據類型的自動轉化

為了避免數據類型自動轉化，更科學的寫法是直接聲明常量為對應的基本數據類型。

第一段代碼可以這樣寫：

第二段代碼可以這樣寫：

2）藉助開發工具或插件，及早地發現數據類型不匹配問題

在 Eclipse 的問題窗口中，我們會看到這樣的提示：

3）進行常規性單元測試，儘量把問題發現在研發階段

“勿以善小而不為”，不要因為改動很小就不需要進行單元測試了，往往 Bug 都出現在自己過度自信的代碼中。像這種問題，只要進行一次單元測試，是完全可以發現問題的。

注意：進行必要單元測試，適用於以下所有案例，所以下文不再累述。

2 三元表達式拆包

三元表達式是 Java 編碼中的一個固定語法格式：

三元表達式的邏輯為：如果條件表達式成立，則執行表達式 1，否則執行表達式 2。

問題現象

當條件表達式 condition 等於 false 時，直接把 Double 對象 value3 賦值給 Double 對象 result，按道理沒有任何問題，為什麼會拋出空指針異常？

問題分析

通過反編譯代碼，我們得到語句：

的字節碼指令如下：

在第 9 行，加載 Double 對象 value 3 到操作數棧中；在第 10 行，調用 Double 對象 value 3 的 doubleValue 方法。這個時候，由於 value 3 是空對象 null，調用 doubleValue 方法必然拋出拋出空指針異常。但是，為什麼要把控對象 value 3 轉化為基礎數據類型 double 呢？

查閱相關資料，得到三元表達式的類型轉化規則：

• 若兩個表達式類型相同，返回值類型為該類型；

• 若兩個表達式類型不同，但類型不可轉換，返回值類型為 Object 類型；

• 若兩個表達式類型不同，但類型可以轉化，先把包裝數據類型轉化為基本數據類型，然後按照基本數據類型的轉換規則 （byte < short(char)< int < long < float < double） 來轉化，返回值類型為優先級最高的基本數據類型。

根據規則分析，表達式 1（value1 * value2）的類型為基礎數據類型 double，表達式 2（value 3）的類型為包裝數據類型 Double，根據三元表達式的類型轉化規則判斷，最終的表達式類型為基礎數據類型 double。所以，當條件表達式 condition 為 false 時，需要把空 Double 對象 value 3 轉化為基礎數據類型 double，於是就調用了 value 3 的 doubleValue 方法進行拆包，當然會拋出空指針異常。

避坑方法

1）儘量避免使用三元表達式，可以採用 if-else 語句代替

如果三元表達式中有包裝數據類型的算術計算，可以考慮利用 if-else 語句代替。改寫代碼如下：

2）儘量使用基本數據類型，避免包裝數據類型的拆裝包

如果在三元表達式中有算術計算，儘量使用基本數據類型，避免包裝數據類型的拆裝包。改寫代碼如下：

3 泛型對象賦值

Java 泛型是 JDK 1.5 中引入的一個新特性，其本質是參數化類型，即把數據類型做為一個參數使用。

在做用戶數據分頁查詢時，因為筆誤編寫了如下代碼：

1）PageDataVO.java

2）UserDAO.java

3）UserService.java

public PageDataVO<uservo> queryUser(UserQueryVO query) { List<userdo> dataList = null;/<userdo>/<uservo>

以上代碼沒有任何編譯問題，但是卻把 UserDO 中一些涉密字段返回給前端。細心的讀者可能已經發現了，在 UserService 類的 queryUser 方法的語句 return new PageDataVO(totalCount, dataList); 中，我們把 List<userdo> 對象 dataList 賦值給了 PageDataVO<uservo> 的 List<uservo> 字段 dataList。/<uservo>/<uservo>/<userdo>

問題是：為什麼開發工具不報編譯錯誤啦？

問題分析

由於歷史原因，參數化類型和原始類型需要兼容。我們以 ArrayList 舉例子，來看看如何兼容的。

以前的寫法：

考慮到與以前的代碼兼容，各種對象引用之間傳值，必然會出現以下的情況：

所以，Java 編譯器對以上兩種類型進行了兼容，不會出現編譯錯誤，但會出現編譯告警。但是，我的開發工具在編譯時真沒出現過告警。

再來分析我們遇到的問題，實際上同時命中了兩種情況：

• 把 List<userdo> 對象賦值給 List，命中了第一種情況；/<userdo>

• 把 PageDataVO 對象賦值給 PageDataVO<uservo>，命中了第二種情況。/<uservo>

最終的效果就是：我們神奇地把 List<userdo> 對象賦值給了 List<uservo>。/<uservo>/<userdo>

問題的根源就是：我們在初始化 PageDataVO 對象時，沒有要求強制進行類型檢查。

避坑方法

1）在初始化泛型對象時，推薦使用 diamond 語法

在《 Java 開發手冊》中，有這麼一條推薦規則：

【推薦】集合泛型定義時，在 JDK7 及以上，使用 diamond 語法或全省略。

說明：菱形泛型，即 diamond，直接使用<>來指代前邊已經指定的類型。

正例：

其實，初始化泛型對象時，全省略是不推薦的。這樣會避免類型檢查，從而造成上面的問題。

在初始化泛型對象時，推薦使用 diamond 語法，代碼如下：

現在，在 Eclipse 的問題窗口中，我們會看到這樣的錯誤：

於是，我們就知道忘記把 List<userdo> 對象轉化為 List<uservo> 對象了。/<uservo>/<userdo>

4 泛型屬性拷貝

Spring 的 BeanUtils.copyProperties 方法，是一個很好用的屬性拷貝工具方法。

問題現象

根據數據庫開發規範，數據庫表格必須包含 id，gmt_create，gmt_modified 三個字段。其中，id 這個字段，可能根據數據量不同，採用 int 或 long 類型。

首先，定義了一個 BaseDO 基類：

針對 user 表，定義了一個 UserDO 類：

對於查詢接口，定義了一個 UserVO 類：

實現查詢用戶服務接口，實現代碼如下：

通過測試，我們會發現一個問題——調用查詢用戶服務接口，用戶 ID 的值並沒有返回。

題分析

通過 Debug 模式運行，進入到 BeanUtils.copyProperties 工具方法內部，得到以下內容：

原來，UserDO 類的 getId 方法返回類型不是 Long 類型，而是被泛型還原成了 Object 類型。而下面的 ClassUtils.isAssignable 工具方法，判斷是否能夠把 Object 類型賦值給 Long 類型，當然會返回false導致不能進行屬性拷貝。

為什麼作者不考慮"先獲取屬性值，再判斷能否賦值”？建議代碼如下：

避坑方法

1）不要盲目地相信第三方工具包，任何工具包都有可能存在問題

在 Java 中，存在很多第三方工具包，比如：Apache 的 commons-lang3、commons-collections，Google 的 guava……都是很好用的第三方工具包。但是，不要盲目地相信第三方工具包，任何工具包都有可能存在問題。

2）如果需要拷貝的屬性較少，可以手動編碼進行屬性拷貝

用 BeanUtils.copyProperties 反射拷貝屬性，主要優點是節省了代碼量，主要缺點是導致程序性能下降。所以，如果需要拷貝的屬性較少，可以手動編碼進行屬性拷貝。

5 Set 對象排重

在 Java 語言中，Set 數據結構可以用於對象排重，常見的 Set 類有 HashSet、LinkedHashSet 等。

問題現象

編寫了一個城市輔助類，從 CSV 文件中讀取城市數據：

代碼中使用 HashSet 數據結構，目的是為了避免城市數據重複，對讀取的城市數據進行強制排重。

當輸入文件內容如下時：

解析後的 JSON 結果如下：

：[{"code":"010","name":"北京"},{"code":"020","name":"廣州"},{"code":"010","name":"北京"}]

但是，並沒有對城市“北京”進行排重。

問題分析

當向集合 Set 中增加對象時，首先集合計算要增加對象的 hashCode，根據該值來得到一個位置用來存放當前對象。如在該位置沒有一個對象存在的話，那麼集合 Set 認為該對象在集合中不存在，直接增加進去。如果在該位置有一個對象存在的話，接著將準備增加到集合中的對象與該位置上的對象進行 equals 方法比較：如果該 equals 方法返回 false，那麼集合認為集合中不存在該對象，就把該對象放在這個對象之後；如果 equals 方法返回 true，那麼就認為集合中已經存在該對象了，就不會再將該對象增加到集合中了。所以，在哈希表中判斷兩個元素是否重複要使用到 hashCode 方法和 equals 方法。hashCode 方法決定數據在表中的存儲位置，而 equals 方法判斷表中是否存在相同的數據。

分析上面的問題，由於沒有重寫 City 類的 hashCode 方法和 equals 方法，就會採用 Object 類的 hashCode 方法和 equals 方法。其實現如下：

可以看出：Object 類的 hashCode 方法是一個本地方法，返回的是對象地址；Object 類的 equals 方法只比較對象是否相等。所以，對於兩條完全一樣的北京數據，由於在解析時初始化了不同的 City 對象，導致 hashCode 方法和 equals 方法值都不一樣，必然被 Set 認為是不同的對象，所以沒有進行排重。

那麼，我們就重寫把 City 類的 hashCode 方法和 equals 方法，代碼如下：

重新支持測試程序，解析後的 JSON 結果如下：

結果正確，已經對城市“北京”進行排重。

避坑方法

1）當確定數據唯一時，可以使用 List 代替 Set

當確定解析的城市數據唯一時，就沒有必要進行排重操作，可以直接使用 List 來存儲。

2）當確定數據不唯一時，可以使用 Map 代替 Set

當確定解析的城市數據不唯一時，需要安裝城市名稱進行排重操作，可以直接使用 Map 進行存儲。為什麼不建議實現 City 類的 hashCode 方法，再採用 HashSet 來實現排重呢？首先，不希望把業務邏輯放在模型 DO 類中；其次，把排重字段放在代碼中，便於代碼的閱讀、理解和維護。

3）遵循 Java 語言規範，重寫 hashCode 方法和 equals 方法

不重寫 hashCode 方法和 equals 方法的自定義類不應該在 Set 中使用。

6 公有方法代理

SpringCGLIB 代理生成的代理類是一個繼承被代理類，通過重寫被代理類中的非 final 的方法實現代理。所以，SpringCGLIB 代理的類不能是 final 類，代理的方法也不能是 final 方法，這是由繼承機制限制的。

問題現象

這裡舉例一個簡單的例子，只有超級用戶才有刪除公司的權限，並且所有服務函數被 AOP 攔截處理異常。例子代碼如下：

1）UserService.java

2）CompanyService.java

if (!Objects.equals(operatorId, userService.getSuperUser().getId())) {

當我們調用 CompanyService 的 deleteCompany 方法時，居然也拋出空指針異常 （NullPointerException），因為調用 UserService 類的 getSuperUser 方法獲取的超級用戶為 null。但是，我們在 CompanyService 類的 deleteCompany 方法中，每次都通過 UserService 類的 setSuperUser 方法強制指定了超級用戶，按道理通過 UserService 類的 getSuperUser 方法獲取到的超級用戶不應該為 null。其實，這個問題也是由 AOP 代理導致的。

問題分析

使用 SpringCGLIB 代理類時，Spring 會創建一個名為 UserService$$EnhancerBySpringCGLIB$$???????? 的代理類。反編譯這個代理類，得到以下主要代碼：

public class UserService$$EnhancerBySpringCGLIB$$a2c3b345 extends UserService implements SpringProxy

可以看出，這個代理類繼承了 UserService 類，只代理了 setSuperUser 方法，但是沒有代理 getSuperUser 方法。所以，當我們調用 setSuperUser 方法時，設置的

可以看出，這個代理類繼承了 UserService 類，只代理了 setSuperUser 方法，但是沒有代理 getSuperUser 方法。所以，當我們調用 setSuperUser 方法時，設置的是原始對象實例的 superUser 字段值；而當我們調用 getSuperUser 方法時，獲取的是代理對象實例的 superUser 字段值。如果把這兩個方法的 final 修飾符互換，同樣存在獲取超級用戶為 null 的問題。

避坑方法

1）嚴格遵循 CGLIB 代理規範，被代理的類和方法不要加 final 修飾符

嚴格遵循 CGLIB 代理規範，被代理的類和方法不要加 final 修飾符，避免動態代理操作對象實例不同（原始對象實例和代理對象實例），從而導致數據不一致或空指針問題。

2）縮小 CGLIB 代理類的範圍，能不用被代理的類就不要被代理

縮小 CGLIB 代理類的範圍，能不用被代理的類就不要被代理，即可以節省內存開銷，又可以提高函數調用效率。

7 公有字段代理

在 fastjson 強制升級到 1.2.60 時踩過一個坑，作者為了開發快速，在 ParseConfig 中定義了：

在我們的項目中繼承了該類，同時又被 AOP 動態代理了，於是一行代碼引起了一場“血案”。

問題現象

仍然使用上章的例子，但是把獲取、設置方法刪除，定義了一個公有字段。例子代碼如下：

1）UserService.java

2）CompanyService.java

當我們調用 CompanyService 的 deleteCompany 方法時，居然拋出空指針異常 （NullPointerException）。經過調試打印，發現是 UserService 的 superUser 變量為 null。如果把代理刪除，就不會出現空指針異常，說明這個問題是由 AOP 代理導致的。

問題分析

使用 SpringCGLIB 代理類時，Spring 會創建一個名為 UserService$$EnhancerBySpringCGLIB$$???????? 的代理類。這個代理類繼承了 UserService 類，並覆蓋了 UserService 類中的所有非 final 的 public 的方法。但是，這個代理類並不調用 super 基類的方法；相反，它會創建的一個成員 userService 並指向原始的 UserService 類對象實例。現在，內存中存在兩個對象實例：一個是原始的 UserService 對象實例，另一個指向 UserService 的代理對象實例。這個代理類只是一個虛擬代理，它繼承了 UserService 類，並且具有與 UserService 相同的字段，但是它從來不會去初始化和使用它們。所以，一但通過這個代理類對象實例獲取公有成員變量時，將返回一個默認值 null。

避坑方法

1）當確定字段不可變時，可以定義為公有靜態常量

當確定字段不可變時，可以定義為公有靜態常量，並用類名稱 + 字段名稱訪問。類名稱 + 字段名稱訪問公有靜態常量，與類實例的動態代理無關。

2）當確定字段不可變時，可以定義為私有成員變量

當確定字段不可變時，可以定義為私有成員變量，提供一個公有 Getter 方法獲取該變量值。當該類實例被動態代理時，代理方法會調用被代理的 Getter 方法，從而返回被代理類的成員變量值。

3）遵循 JavaBean 編碼規範，不要定義公有成員變量

遵循 JavaBean 編碼規範，不要定義公有成員變量。JavaBean 規範如下：

• JavaBean 類必須是一個公共類，並將其訪問屬性設置為 public，如：public class User{......}

• JavaBean 類必須有一個空的構造函數：類中必須有一個不帶參數的公用構造器

• 一個 JavaBean 類不應有公共實例變量，類變量都為 private，如：private Integer id;

• 屬性應該通過一組 getter / setter 方法來訪問

後記

最後，推薦大家閱讀一下《Java 開發手冊》，這本手冊讓我受益匪淺。只要學習理解了《Java 開發手冊》，就能在日常的 Java 開發工作中，避免踩到很多常識性的 Java 坑。

優逸客（微信公眾號sx-uek）UI設計、Web全棧開發、JAVA開發等課程免費試聽課

4月學習堅持不懈，9月就業傲視群雄！

閱讀更多 優逸客 的文章

關鍵字: Eclipse 泛函編程 代碼