Photo?@?Drew Farwell?

文? |??常意

1.前言

---

中國有句老話叫"事不過三"，指一個人犯了同樣的錯誤，一次兩次三次還可以原諒，超過三次就不可原諒了。有人指出這個“三”是虛數(shù)，用來泛指多次，所以"事不過三"不包括“三”。至于"事不過三"包不包括“三”，可能跟每個人的底線有關(guān)系，屬于哲學范疇，不在本文的討論范圍之內(nèi)。

寫代碼也是如此，同一個代碼“坑”，踩第一次叫"長了經(jīng)驗"，踩第二次叫"加深印象"，踩第三次叫"不長心眼"，踩三次以上就叫"不可救藥"。在本文中，筆者總結(jié)了一些代碼坑，描述了問題現(xiàn)象，進行了問題分析，給出了避坑方法。希望大家在日常編碼中，遇到了這類代碼坑，能夠提前避讓開來。

1.對象比較方法

JDK1.7 提供的 Objects.equals 方法，非常方便地實現(xiàn)了對象的比較，有效地避免了繁瑣的空指針檢查。

1.1.問題現(xiàn)象

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

Short shortValue = (short)12345;
System.out.println(shortValue == 12345); // true
System.out.println(12345 == shortValue); // true
Integer intValue = 12345;
System.out.println(intValue == 12345); // true
System.out.println(12345 == intValue); // true
Long longValue = 12345L;
System.out.println(longValue == 12345); // true
System.out.println(12345 == longValue); // true

從 JDK1.7 之后，提供了 Objects.equals 方法，并推薦使用函數(shù)式編程，更改代碼如下：

Short shortValue = (short)12345;
System.out.println(Objects.equals(shortValue, 12345)); // false
System.out.println(Objects.equals(12345, shortValue)); // false
Integer intValue = 12345;
System.out.println(Objects.equals(intValue, 12345)); // true
System.out.println(Objects.equals(12345, intValue)); // true
Long longValue = 12345L;
System.out.println(Objects.equals(longValue, 12345)); // false
System.out.println(Objects.equals(12345, longValue)); // false

為什么直接把==替換為 Objects.equals 方法會導致輸出結(jié)果不一樣？

1.2.問題分析

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

7 ? getstatic java.lang.System.out : java.io.PrintStream [22]
10 ?aload_1 [shortValue]
11 ?invokevirtual java.lang.Short.shortValue() : short [28]
14 ?sipush 12345
17 ?if_icmpne 24
20 ?iconst_1
21 ?goto 25
24 ?iconst_0
25 ?invokevirtual java.io.PrintStream.println(boolean) : void [32]

原來，編譯器會判斷包裝數(shù)據(jù)類型對應的基本數(shù)據(jù)類型，并采用這個基本數(shù)據(jù)類型的指令進行比較（比如上面字節(jié)碼指令中的sipush和if_icmpne等），相當于編譯器自動對常量進行了數(shù)據(jù)類型的強制轉(zhuǎn)化。

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

7 ? getstatic java.lang.System.out : java.io.PrintStream [22]
10 ?aload_1 [shortValue]
11 ?sipush 12345
14 ?invokestatic java.lang.Integer.valueOf(int) : java.lang.Integer [28]
17 ?invokestatic java.util.Objects.equals(java.lang.Object, java.lang.Object) : boolean [33]
20 ?invokevirtual java.io.PrintStream.println(boolean) : void [39]

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

在 Java 語言中，整數(shù)的默認數(shù)據(jù)類型是 int ，小數(shù)的默認數(shù)據(jù)類型是 double 。

下面來分析一下 Objects.equals 方法的代碼實現(xiàn)：

public static boolean equals(Object a, Object b) {
 ? ?return (a == b) || (a != null && a.equals(b));
}

其中，語句 “a.equals(b)” 將會使用到 Short.equals 方法。

Short.equals 方法的代碼實現(xiàn)為：

public boolean equals(Object obj) {
 ? ?if (obj instanceof Short) {
 ? ? ? ?return value == ((Short)obj).shortValue();
 ?  }
 ? ?return false;
}

通過代碼實現(xiàn)分析：對應語句"System.out.println(Objects.equals(shortValue, 12345));"，因為 Objects.equals 的兩個參數(shù)對象類型不一致，一個是包裝數(shù)據(jù)類型 Short ，另一個是包裝數(shù)據(jù)類型 Integer ，所以最終的比較結(jié)果必然是 false 。同樣，語句 “System.out.println(Objects.equals(intValue, 12345));” ，因為 Objects.equals 的兩個參數(shù)對象類型一致，都是包裝數(shù)據(jù)類型Integer且取值一樣，所以最終的比較結(jié)果必然是 true 。

1.3.避坑方法

1、保持良好的編碼習慣，避免數(shù)據(jù)類型的自動轉(zhuǎn)化

為了避免數(shù)據(jù)類型自動轉(zhuǎn)化，更科學的寫法是直接聲明常量為對應的基本數(shù)據(jù)類型。

第一段代碼可以這樣寫：

Short shortValue = (short)12345;
System.out.println(shortValue == (short)12345); // true
System.out.println((short)12345 == shortValue); // true
Integer intValue = 12345;
System.out.println(intValue == 12345); // true
System.out.println(12345 == intValue); // true
Long longValue = 12345L;
System.out.println(longValue == 12345L); // true
System.out.println(12345L == longValue); // true

第二段代碼可以這樣寫：

Short shortValue = (short)12345;
System.out.println(Objects.equals(shortValue, (short)12345)); // true
System.out.println(Objects.equals((short)12345, shortValue)); // true
Integer intValue = 12345;
System.out.println(Objects.equals(intValue, 12345)); // true
System.out.println(Objects.equals(12345, intValue)); // true
Long longValue = 12345L;
System.out.println(Objects.equals(longValue, 12345L)); // true
System.out.println(Objects.equals(12345L, longValue)); // true

2、借助開發(fā)工具或插件，及早地發(fā)現(xiàn)數(shù)據(jù)類型不匹配問題

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

Unlikely argument type for equals(): int seems to be unrelated to Short
Unlikely argument type for equals(): Short seems to be unrelated to int
Unlikely argument type for equals(): int seems to be unrelated to Long
Unlikely argument type for equals(): Long seems to be unrelated to int

通過 FindBugs 插件掃描，我們會看到這樣的警告：

Call to Short.equals(Integer) in xxx.Xxx.main(String[]) [Scariest(1), High confidence]
Call to Integer.equals(Short) in xxx.Xxx.main(String[]) [Scariest(1), High confidence]
Call to Long.equals(Integer) in xxx.Xxx.main(String[]) [Scariest(1), High confidence]
Call to Integer.equals(Long) in xxx.Xxx.main(String[]) [Scariest(1), High confidence]

3、進行常規(guī)性單元測試，盡量把問題發(fā)現(xiàn)在研發(fā)階段

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

2.三元表達式拆包

---

三元表達式是 Java 編碼中的一個固定語法格式：“條件表達式？表達式 1 ：表達式 2 ”。三元表達式的邏輯為：“如果條件表達式成立，則執(zhí)行表達式 1 ，否則執(zhí)行表達式 2 ”。

2.1.問題現(xiàn)象

boolean condition = false;
Double value1 = 1.0D;
Double value2 = 2.0D;
Double value3 = null;
Double result = condition ? value1 * value2 : value3; // 拋出空指針異常

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

2.2.問題分析

通過反編譯代碼，我們得到語句"Double result = condition ? value1 * value2 : value3;"的字節(jié)碼指令如下：

17 ?iload_1 [condition]
18 ?ifeq 33
21 ?aload_2 [value1]
22 ?invokevirtual java.lang.Double.doubleValue() : double [24]
25 ?aload_3 [value2]
26 ?invokevirtual java.lang.Double.doubleValue() : double [24]
29 ?dmul
30 ?goto 38
33 ?aload 4 [value3]
35 ?invokevirtual java.lang.Double.doubleValue() : double [24]
38 ?invokestatic java.lang.Double.valueOf(double) : java.lang.Double [16]
41 ?astore 5 [result]
43 ?getstatic java.lang.System.out : java.io.PrintStream [28]
46 ?aload 5 [result]

在第 33 行，加載 Double 對象 value3 到操作數(shù)棧中；在第 35 行，調(diào)用 Double 對象 value3 的 doubleValue 方法。這個時候，由于 value3 是空對象 null ，調(diào)用? doubleValue ?方法必然拋出拋出空指針異常。但是，為什么要把空對象 value3 轉(zhuǎn)化為基礎數(shù)據(jù)類型 double ？

查閱相關(guān)資料，得到三元表達式的類型轉(zhuǎn)化規(guī)則：

1. 若兩個表達式類型相同，返回值類型為該類型；
2. 若兩個表達式類型不同，但類型不可轉(zhuǎn)換，返回值類型為Object類型；
3. 若兩個表達式類型不同，但類型可以轉(zhuǎn)化，先把包裝數(shù)據(jù)類型轉(zhuǎn)化為基本數(shù)據(jù)類型，然后按照基本數(shù)據(jù)類型的轉(zhuǎn)換規(guī)則（byte

根據(jù)規(guī)則分析，表達式 1（value1 * value2）計算后返回基礎數(shù)據(jù)類型 double ，表達式 2（value3） 返回包裝數(shù)據(jù)類型 Double ，根據(jù)三元表達式的類型轉(zhuǎn)化規(guī)則判斷，最終的返回類型為基礎數(shù)據(jù)類型 double 。所以，當條件表達式 condition 等于 false 時，需要把空對象 value3 轉(zhuǎn)化為基礎數(shù)據(jù)類型 double ，于是就調(diào)用了 value3 的 doubleValue 方法拋出了空指針異常。

可以用以下案例驗證三元表達式的類型轉(zhuǎn)化規(guī)則：

boolean condition = false;
Double value1 = 1.0D;
Double value2 = 2.0D;
Double value3 = null;
Integer value4 = null;
// 返回類型為Double,不拋出空指針異常
Double result1 = condition ? value1 : value3;
// 返回類型為double,會拋出空指針異常
Double result2 = condition ? value1 : value4;
// 返回類型為double,不拋出空指針異常
Double result3 = !condition ? value1 * value2 : value3;
// 返回類型為double,會拋出空指針異常
Double result4 = condition ? value1 * value2 : value3;

2.3.避坑方法

1、盡量避免使用三元表達式，可以采用 if-else 語句代替

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

boolean condition = false;
Double value1 = 1.0D;
Double value2 = 2.0D;
Double value3 = null;
Double result;
if (condition) {
 ? ?result = value1 * value2;
} else {
 ? ?result = value3;
}

2、盡量使用基本數(shù)據(jù)類型，避免數(shù)據(jù)類型的自動轉(zhuǎn)化

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

boolean condition = false;
double value1 = 1.0D;
double value2 = 2.0D;
double value3 = 3.0D;
double result = condition ? value1 * value2 : value3;

3、進行覆蓋性單元測試，盡量把問題發(fā)現(xiàn)在研發(fā)階段

像這種問題，只要編寫一些單元測試用例，進行一些覆蓋性測試，是完全可以提前發(fā)現(xiàn)的。

3.泛型對象賦值

---

?Java 泛型是 JDK1.5 中引入的一個新特性，其本質(zhì)是參數(shù)化類型，即把數(shù)據(jù)類型做為一個參數(shù)使用。

3.1.問題現(xiàn)象

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

1、PageDataVO.java：

/** 分頁數(shù)據(jù)VO類 */
@Getter
@Setter
@ToString
@NoArgsConstructor
@AllArgsConstructor
public class PageDataVO {
 ? ?/** 總共數(shù)量 */
 ? ?private Long totalCount;
 ? ?/** 數(shù)據(jù)列表 */
 ? ?private List dataList;
}

2、UserDAO.java：

/** 用戶DAO接口 */
@Mapper
public interface UserDAO {
 ? ?/** 統(tǒng)計用戶數(shù)量 */
 ? ?public Long countUser(@Param("query") UserQueryVO query);
 ? ?/** 查詢用戶信息 */
 ? ?public List queryUser(@Param("query") UserQueryVO query);
}

3、UserService.java：

/** 用戶服務類 */
@Service
public class UserService {
 ? ?/** 用戶DAO */
 ? ?@Autowired
 ? ?private UserDAO userDAO;

 ? ?/** 查詢用戶信息 */
 ? ?public PageDataVO queryUser(UserQueryVO query) {
 ? ? ? ?List dataList = null;
 ? ? ? ?Long totalCount = userDAO.countUser(query);
 ? ? ? ?if (Objects.nonNull(totalCount) && totalCount.compareTo(0L) > 0) {
 ? ? ? ? ? ?dataList = userDAO.queryUser(query);
 ? ? ?  }
 ? ? ? ?return new PageDataVO(totalCount, dataList);
 ?  }
}

4、UserController.java：

/** 用戶控制器類 */
@Controller
@RequestMapping("/user")
public class UserController {
 ? ?/** 用戶服務 */
 ? ?@Autowired
 ? ?private UserService userService;

 ? ?/** 查詢用戶 */
 ? ?@ResponseBody
 ? ?@RequestMapping(value = "/query", method = RequestMethod.POST)
 ? ?public Result> queryUser(@RequestBody UserQueryVO query) {
 ? ? ? ?PageDataVO pageData = userService.queryUser(query);
 ? ? ? ?return ResultBuilder.success(pageData);
 ?  }
}

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

問題是：為什么開發(fā)工具不報編譯錯誤啦？

3.2.問題分析

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

以前的寫法：

ArrayList list = new ArrayList();

現(xiàn)在的寫法：

ArrayList list = new ArrayList();

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

// 第一種情況
ArrayList list1 = new ArrayList();
// 第二種情況
ArrayList list2 = new ArrayList();

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

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

1、把 List 對象賦值給 List ，命中了第一種情況；

2、把 PageDataVO 對象賦值給 PageDataVO ，命中了第二種情況。

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

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

3.3.避坑方法

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

在《阿里巴巴 Java 開發(fā)手冊》中，有這么一條推薦規(guī)則：

【推薦】集合泛型定義時，在 JDK7 及以上，使用 diamond 語法或全省略。說明：菱形泛型，即 diamond，直接使用<>來指代前邊已經(jīng)指定的類型。正例：

// <> diamond 方式
HashMap userCache = new HashMap<>(16);
// 全省略方式
ArrayList users = new ArrayList(10);

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

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

return new PageDataVO<>(totalCount, dataList);

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

Cannot infer type arguments for PageDataVO<>

于是，我們就知道忘了把 List 對象轉(zhuǎn)化為 List 對象了。

2、在進行單元測試時，需要對比數(shù)據(jù)內(nèi)容

在進行單元測試時，運行正常是一個指標，但數(shù)據(jù)正確才是更重要的指標。

4.泛型屬性拷貝

---

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

4.1.問題現(xiàn)象

根據(jù)數(shù)據(jù)庫開發(fā)規(guī)范，數(shù)據(jù)庫表格必須包含 id，gmt_create，gmt_modified 三個字段。其中， id ?這個字段，可能根據(jù)數(shù)據(jù)量不同，采用 int 或 long 類型（注意：阿里規(guī)范要求必須是 long 類型，這里為了舉例說明，允許為 int 或 long 類型）。

所以，把這三個字段抽出來，定義了一個 BaseDO 基類：

/** 基礎DO類 */
@Getter
@Setter
@ToString
public class BaseDO {
 ? ?private T id;
 ? ?private Date gmtCreate;
 ? ?private Date gmtModified;
}

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

/** 用戶DO類 */
@Getter
@Setter
@ToString
public class UserDO extends BaseDO{
 ? ?private String name;
 ? ?private String description;
}

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

/** 用戶VO類 */
@Getter
@Setter
@ToString
public static class UserVO {
 ? ?private Long id;
 ? ?private String name;
 ? ?private String description;
}

實現(xiàn)查詢用戶服務接口，實現(xiàn)代碼如下：

/** 用戶服務類 */
@Service
public class UserService {
 ? ?/** 用戶DAO */
 ? ?@Autowired
 ? ?private UserDAO userDAO;

 ? ?/** 查詢用戶 */
 ? ?public List queryUser(UserQueryVO query) {
 ? ? ? ?// 查詢用戶信息
 ? ? ? ?List userDOList = userDAO.queryUser(query);
 ? ? ? ?if (CollectionUtils.isEmpty()) {
 ? ? ? ? ? ?return Collections.emptyList();
 ? ? ?  }

 ? ? ? ?// 轉(zhuǎn)化用戶列表
 ? ? ? ?List userVOList = new ArrayList<>(userDOList.size());
 ? ? ? ?for (UserDO userDO : userDOList) {
 ? ? ? ? ? ?UserVO userVO = new UserVO();
 ? ? ? ? ? ?BeanUtils.copyProperties(userDO, userVO);
 ? ? ? ? ? ?userVOList.add(userVO);
 ? ? ?  }

 ? ? ? ?// 返回用戶列表
 ? ? ? ?return userVOList;
 ?  }
}

通過測試，我們會發(fā)現(xiàn)一個問題——調(diào)用查詢用戶服務接口，用戶 ID 的值并沒有返回。

[{"description":"This is a tester.","name":"tester"},...]

4.2.問題分析

按道理，UserDO 類和 UserVO 類的 id 字段，類型都是 Long 類型，不存在類型不可轉(zhuǎn)化，應該能夠正常賦值。嘗試手工賦值，代碼如下：

for (UserDO userDO : userDOList) {
 ? ?UserVO userVO = new UserVO();
 ? ?userVO.setId(userDO.getId());
 ? ?userVO.setName(userDO.getName());
 ? ?userVO.setDescription(userDO.getDescription());
 ? ?userVOList.add(userVO);
}

經(jīng)過測試，上面代碼返回結(jié)果正常，用戶ID的值成功返回。

那么，就是 BeanUtils.copyProperties 工具方法的問題了。用 Debug 模式運行，進入到 BeanUtils.copyProperties 工具方法內(nèi)部，得到以下數(shù)據(jù)：

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

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

Object value = readMethod.invoke(source);
if (Objects.nonNull(value) && ClassUtils.isAssignable(writeMethod.getParameterTypes()[0], value.getClass())) {
 ? ... // 賦值相關(guān)代碼
}

4.3.避坑方法

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

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

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

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

3、一定要進行單元測試，一定要對比數(shù)據(jù)內(nèi)容

在編寫完代碼后，一定要進行單元測試，一定要對比數(shù)據(jù)內(nèi)容。切莫想當然地認為：工具包很成熟、代碼也很簡單，不可能出現(xiàn)問題。

5.Set對象排重

---

在 Java 語言中， Set 數(shù)據(jù)結(jié)構(gòu)可以用于對象排重，常見的 Set 類有 HashSet 、 LinkedHashSet 等。

5.1.問題現(xiàn)象

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

/** 城市輔助類 */
@Slf4j
public class CityHelper {
 ? ?/** 測試主方法 */
 ? ?public static void main(String[] args) {
 ? ? ? ?Collection cityCollection = readCities2("cities.csv");
 ? ? ? ?log.info(JSON.toJSONString(cityCollection));
 ?  }

/** 讀取城市 */
 ? ?public static Collection readCities(String fileName) {
 ? ? ? ?try (FileInputStream stream = new FileInputStream(fileName);
 ? ? ? ? ? ?InputStreamReader reader = new InputStreamReader(stream, "GBK");
 ? ? ? ? ? ?CSVParser parser = new CSVParser(reader, CSVFormat.DEFAULT.withHeader())) {
 ? ? ? ? ? ?Set citySet = new HashSet<>(1024);
 ? ? ? ? ? ?Iterator iterator = parser.iterator();
 ? ? ? ? ? ?while (iterator.hasNext()) {
 ? ? ? ? ? ? ? ?citySet.add(parseCity(iterator.next()));
 ? ? ? ? ?  }
 ? ? ? ? ? ?return citySet;
 ? ? ?  } catch (IOException e) {
 ? ? ? ? ? ?log.warn("讀取所有城市異常", e);
 ? ? ?  }
 ? ? ? ?return Collections.emptyList();
 ?  }

/** 解析城市 */
 ? ?private static City parseCity(CSVRecord record) {
 ? ? ? ?City city = new City();
 ? ? ? ?city.setCode(record.get(0));
 ? ? ? ?city.setName(record.get(1));
 ? ? ? ?return city;
 ?  }

 ? ?/** 城市類 */
 ? ?@Getter
 ? ?@Setter
 ? ?@ToString
 ? ?private static class City {
 ? ? ? ?/** 城市編碼 */
 ? ? ? ?private String code;
 ? ? ? ?/** 城市名稱 */
 ? ? ? ?private String name;
 ?  }
}

代碼中使用 HashSet 數(shù)據(jù)結(jié)構(gòu)，目的是為了避免城市數(shù)據(jù)重復，對讀取的城市數(shù)據(jù)進行強制排重。

當輸入文件內(nèi)容如下時：

編碼,名稱
010,北京
020,廣州
010,北京

解析后的 JSON 結(jié)果如下：

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

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

5.2.問題分析

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

分析上面的問題，由于沒有重寫 City 類的 hashCode 方法和 equals 方法，就會采用 Object 類的 hashCode 方法和 equals 方法。其實現(xiàn)如下：

public native int hashCode();
public boolean equals(Object obj) {
 ? ?return (this == obj);
}

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

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

/** 城市類 */
@Getter
@Setter
@ToString
private static class City {
 ? ?/** 城市編碼 */
 ? ?private String code;
 ? ?/** 城市名稱 */
 ? ?private String name;

 ? ?/** 判斷相等 */
 ? ?@Override
 ? ?public boolean equals(Object obj) {
 ? ? ? ?if (obj == this) {
 ? ? ? ? ? ?return true;
 ? ? ?  }
 ? ? ? ?if (Objects.isNull(obj)) {
 ? ? ? ? ? ?return false;
 ? ? ?  }
 ? ? ? ?if (obj.getClass() != this.getClass()) {
 ? ? ? ? ? ?return false;
 ? ? ?  }
 ? ? ? ?return Objects.equals(this.code, ((City)obj).code);
 ?  }

 ? ?/** 哈希編碼 */
 ? ?@Override
 ? ?public int hashCode() {
 ? ? ? ?return Objects.hashCode(this.code);
 ?  }
}

重新支持測試程序，解析后的JSON結(jié)果如下：

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

結(jié)果正確，已經(jīng)對城市“北京”進行排重。

5.3.避坑方法

1、當確定數(shù)據(jù)唯一時，可以使用List代替Set

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

List citySet = new ArrayList<>(1024);
Iterator iterator = parser.iterator();
while (iterator.hasNext()) {
 ? ?citySet.add(parseCity(iterator.next()));
}
return citySet;

2、當確定數(shù)據(jù)不唯一時，可以使用 Map 代替 Set

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

Map cityMap = new HashMap<>(1024);
Iterator iterator = parser.iterator();
while (iterator.hasNext()) {
 ? ?City city = parseCity(iterator.next());
 ? ?cityMap.put(city.getCode(), city);
}
return cityMap.values();

3、遵循Java語言規(guī)范，重寫hashCode方法和equals方法

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

6.公有方法代理

---

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

6.1.問題現(xiàn)象

這里舉例一個簡單的例子，只有超級用戶才有刪除公司的權(quán)限，并且所有服務函數(shù)被 AOP 攔截處理異常。例子代碼如下：

1、UserService.java：

/** 用戶服務類 */
@Service
public class UserService {
 ? ?/** 超級用戶 */
 ? ?private User superUser;

/** 設置超級用戶 */
 ? ?public void setSuperUser(User superUser) {
 ? ? ? ?this.superUser = superUser;
 ?  }

 ? ?/** 獲取超級用戶 */
 ? ?public final User getSuperUser() {
 ? ? ? ?return this.superUser;
 ?  }
}

2、CompanyService.java：

/** 公司服務類 */
@Service
public class CompanyService {
 ? ?/** 公司DAO */
 ? ?@Autowired
 ? ?private CompanyDAO companyDAO;
 ? ?/** 用戶服務 */
 ? ?@Autowired
 ? ?private UserService userService;

 ? ?/** 刪除公司 */
 ? ?public void deleteCompany(Long companyId, Long operatorId) {
 ? ? ? ?// 設置超級用戶
 ? ? ? ?userService.setSuperUser(new User(0L, "admin", "超級用戶"));

 ? ? ? ?// 驗證超級用戶
 ? ? ? ?if (!Objects.equals(operatorId, userService.getSuperUser().getId())) {
 ? ? ? ? ? ?throw new ExampleException("只有超級用戶才能刪除公司");
 ? ? ?  }

 ? ? ? ?// 刪除公司信息
 ? ? ? ?companyDAO.delete(companyId, operatorId);
 ?  }
}

3、AopConfiguration.java：

/** AOP配置類 */
@Slf4j
@Aspect
@Configuration
public class AopConfiguration {
 ? ?/** 環(huán)繞方法 */
 ? ?@Around("execution(* org.changyi.springboot.service..*.*(..))")
 ? ?public Object around(ProceedingJoinPoint joinPoint) {
 ? ? ? ?try {
 ? ? ? ? ? ?log.info("開始調(diào)用服務方法...");
 ? ? ? ? ? ?return joinPoint.proceed();
 ? ? ?  } catch (Throwable e) {
 ? ? ? ? ? ?log.error(e.getMessage(), e);
 ? ? ? ? ? ?throw new ExampleException(e.getMessage(), e);
 ? ? ?  }
 ?  }
}

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

6.2.問題分析

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

public class UserService$$EnhancerBySpringCGLIB$$a2c3b345 extends UserService implements SpringProxy, Advised, Factory {
 ?  ......
 ? ?public final void setSuperUser(User var1) {
 ? ? ? ?MethodInterceptor var10000 = this.CGLIB$CALLBACK_0;
 ? ? ? ?if (var10000 == null) {
 ? ? ? ? ? ?CGLIB$BIND_CALLBACKS(this);
 ? ? ? ? ? ?var10000 = this.CGLIB$CALLBACK_0;
 ? ? ?  }

 ? ? ? ?if (var10000 != null) {
 ? ? ? ? ? ?var10000.intercept(this, CGLIB$setSuperUser$0$Method, new Object[]{var1}, CGLIB$setSuperUser$0$Proxy);
 ? ? ?  } else {
 ? ? ? ? ? ?super.setSuperUser(var1);
 ? ? ?  }
 ?  }
 ?  ......
}

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

6.3.避坑方法

1、嚴格遵循 CGLIB 代理規(guī)范，被代理的類和方法不要加 final 修飾符

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

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

縮小 CGLIB 代理類的范圍，能不用被代理的類就不要被代理，即可以節(jié)省內(nèi)存開銷，又可以提高函數(shù)調(diào)用效率。

7.公有字段代理

---

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

public class ParseConfig {
 ? ?public final SymbolTable symbolTable = new SymbolTable(4096);
 ?  ......
}

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

7.1.問題現(xiàn)象

---

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

1、UserService.java：

/** 用戶服務類 */
@Service
public class UserService {
 ? ?/** 超級用戶 */
 ? ?public final User superUser = new User(0L, "admin", "超級用戶");
 ?  ......
}

2、CompanyService.java：

/** 公司服務類 */
@Service
public class CompanyService {
 ? ?/** 公司DAO */
 ? ?@Autowired
 ? ?private CompanyDAO companyDAO;
 ? ?/** 用戶服務 */
 ? ?@Autowired
 ? ?private UserService userService;

 ? ?/** 刪除公司 */
 ? ?public void deleteCompany(Long companyId, Long operatorId) {
 ? ? ? ?// 驗證超級用戶
 ? ? ? ?if (!Objects.equals(operatorId, userService.superUser.getId())) {
 ? ? ? ? ? ?throw new ExampleException("只有超級用戶才能刪除公司");
 ? ? ?  }

 ? ? ? ?// 刪除公司信息
 ? ? ? ?companyDAO.delete(companyId, operatorId);
 ?  }
}

3、AopConfiguration.java：

同上一章 AopConfiguration.java 。

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

7.2.問題分析

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

7.3.避坑方法

1、當確定字段不可變時，可以定義為公有靜態(tài)常量

當確定字段不可變時，可以定義為公有靜態(tài)常量，并用類名稱+字段名稱訪問。類名稱+字段名稱訪問公有靜態(tài)常量，與類實例的動態(tài)代理無關(guān)。

/** 用戶服務類 */
@Service
public class UserService {
 ? ?/** 超級用戶 */
 ? ?public static final User SUPER_USER = new User(0L, "admin", "超級用戶");
 ?  ......
}

/** 使用代碼 */
if (!Objects.equals(operatorId, UserService.SUPER_USER.getId())) {
 ? ?throw new ExampleException("只有超級用戶才能刪除公司");
}

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

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

/** 用戶服務類 */
@Service
public class UserService {
 ? ?/** 超級用戶 */
 ? ?private User superUser = new User(0L, "admin", "超級用戶");
 ? ?/** 獲取超級用戶 */
 ? ?public User getSuperUser() {
 ? ? ? ?return this.superUser;
 ?  }
 ?  ......
}

/** 使用代碼 */
if (!Objects.equals(operatorId, userService.getSuperUser().getId())) {
 ? ?throw new ExampleException("只有超級用戶才能刪除公司");
}

3、遵循 JavaBean 編碼規(guī)范，不要定義公有成員變量

遵循 JavaBean 編碼規(guī)范，不要定義公有成員變量。JavaBean 規(guī)范如下：

(1)JavaBean類必須是一個公共類，并將其訪問屬性設置為public，如：public class User{......}(2)JavaBean類必須有一個空的構(gòu)造函數(shù)：類中必須有一個不帶參數(shù)的公用構(gòu)造器(3)一個JavaBean類不應有公共實例變量，類變量都為private，如：private Integer id;(4)屬性應該通過一組getter/setter方法來訪問。

后記

---

人類受益于“類比”思維，舉一反三就是人類的智慧，每當遇到新生事物時，人們往往用類似的已知事物作為參考，能夠加速對新生事物的認知。而人類又受制于“定勢”思維，因為已知事物并不能代表新生事物，而人們又容易形成先入為主的概念，最終導致對新生事物產(chǎn)生誤判。

?寫在最后：
前線推出學習交流群和大廠面試真題，獲取和加群一定要備注：
?最后給讀者整理了一份大廠面試真題，需要的可掃碼微信加我備注：“大廠面試”獲取。




END


前線推出學習交流群，加群一定要備注：

研究/工作方向+地點+學校/公司+昵稱（如java+上海+上交+可可）
根據(jù)格式備注，可更快被通過且邀請進群，領(lǐng)取一份專屬學習禮包
掃碼加我微信進群
大廠內(nèi)推和技術(shù)交流，和前輩大佬們零距離
歷史推薦

10個實用但非常偏執(zhí)的Java編程技巧
為什么大公司一定要使用微服務？
Java 程序員必須掌握的 10 款開源工具！
Java程序員必備的11大Intellij插件
點個在看吧