[[322034]]

日常開發(fā)中總會(huì)遇到各種各樣的“坑”，如何提前規(guī)避呢?本文將分享 Java 開發(fā)中容易遇到的一些坑，并給出詳細(xì)的問題解析和避坑方法。

前言

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

1、對(duì)象比較方法

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

問題現(xiàn)象

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

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

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

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

為什么直接把 == 替換為 Objects.equals 方法就會(huì)導(dǎo)致輸出結(jié)果不一樣?

問題分析

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

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

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

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

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

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

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

通過分析Objects.equals方法的源代碼可知：語句System.out.println(Objects.equals(shortValue, 12345))，因?yàn)?Objects.equals 的兩個(gè)參數(shù)對(duì)象類型不一致，一個(gè)是包裝數(shù)據(jù)類型 Short，另一個(gè)是包裝數(shù)據(jù)類型 Integer，所以最終的比較結(jié)果必然是false;而語句 System.out.println(Objects.equals(intValue, 12345))，因?yàn)镺bjects.equals 的兩個(gè)參數(shù)對(duì)象類型一致，都是包裝數(shù)據(jù)類型 Integer 且取值相同，所以最終的比較結(jié)果必然是 true。

避坑方法

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

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

第一段代碼可以這樣寫：

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

第二段代碼可以這樣寫：

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

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

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

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

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

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

注意：進(jìn)行必要單元測(cè)試，適用于以下所有案例，所以下文不再累述。

2、三元表達(dá)式拆包

三元表達(dá)式是 Java 編碼中的一個(gè)固定語法格式：

條件表達(dá)式?表達(dá)式1：表達(dá)式2

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

問題現(xiàn)象

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

當(dāng)條件表達(dá)式 condition 等于 false 時(shí)，直接把 Double 對(duì)象 value3 賦值給 Double 對(duì)象 result，按道理沒有任何問題，為什么會(huì)拋出空指針異常?

問題分析

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

Double result = condition ? value1 * value2 : value3; 

的字節(jié)碼指令如下：

iload_1 [condition] 
ifeq 33 
aload_2 [value1] 
invokevirtual java.lang.Double.doubleValue() : double [24] 
aload_3 [value2] 
invokevirtual java.lang.Double.doubleValue() : double [24] 
dmul 
goto 38 
aload 4 [value3] 
invokevirtual java.lang.Double.doubleValue() : double [24] 
invokestatic java.lang.Double.valueOf(double) : java.lang.Double [16] 
astore 5 [result] 

在第 9 行，加載 Double 對(duì)象 value 3 到操作數(shù)棧中;在第 10 行，調(diào)用 Double 對(duì)象 value 3 的 doubleValue 方法。這個(gè)時(shí)候，由于 value 3 是空對(duì)象 null，調(diào)用 doubleValue 方法必然拋出拋出空指針異常。但是，為什么要把空對(duì)象 value 3 轉(zhuǎn)化為基礎(chǔ)數(shù)據(jù)類型 double 呢?

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

• 若兩個(gè)表達(dá)式類型相同，返回值類型為該類型;
• 若兩個(gè)表達(dá)式類型不同，但類型不可轉(zhuǎn)換，返回值類型為 Object 類型;
• 若兩個(gè)表達(dá)式類型不同，但類型可以轉(zhuǎn)化，先把包裝數(shù)據(jù)類型轉(zhuǎn)化為基本數(shù)據(jù)類型，然后按照基本數(shù)據(jù)類型的轉(zhuǎn)換規(guī)則 (byte < short(char)< int < long < float < double) 來轉(zhuǎn)化，返回值類型為優(yōu)先級(jí)最高的基本數(shù)據(jù)類型。

根據(jù)規(guī)則分析，表達(dá)式 1(value1 * value2)的類型為基礎(chǔ)數(shù)據(jù)類型 double，表達(dá)式 2(value 3)的類型為包裝數(shù)據(jù)類型 Double，根據(jù)三元表達(dá)式的類型轉(zhuǎn)化規(guī)則判斷，最終的表達(dá)式類型為基礎(chǔ)數(shù)據(jù)類型 double。所以，當(dāng)條件表達(dá)式 condition 為 false 時(shí)，需要把空 Double 對(duì)象 value 3 轉(zhuǎn)化為基礎(chǔ)數(shù)據(jù)類型 double，于是就調(diào)用了 value 3 的 doubleValue 方法進(jìn)行拆包，當(dāng)然會(huì)拋出空指針異常。

避坑方法

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

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

if (condition) { 
  result = value1 * value2; 
} else { 
  result = value3; 
} 

2)盡量使用基本數(shù)據(jù)類型，避免包裝數(shù)據(jù)類型的拆裝包

如果在三元表達(dá)式中有算術(shù)計(jì)算，盡量使用基本數(shù)據(jù)類型，避免包裝數(shù)據(jù)類型的拆裝包。改寫代碼如下：

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

3、泛型對(duì)象賦值

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

問題現(xiàn)象

在做用戶數(shù)據(jù)分頁查詢時(shí)，因?yàn)楣P誤編寫了如下代碼：

1)PageDataVO.java

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

2)UserDAO.java

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

3)UserService.java

/** 用戶服務(wù)類 */@Service 
public class UserService { 
  /** 用戶DAO */ 
  @Autowired 
  private UserDAO userDAO; 
  /** 查詢用戶信息 */ 
  public PageDataVO<UserVO> queryUser(UserQueryVO query) {     List<UserDO> dataList = null; 
    Long totalCount = userDAO.countUser(query); 
    if (Objects.nonNull(totalCount) && totalCount.compareTo(0L) > 0) { 
      dataList = userDAO.queryUser(query); 
    } 
    return new PageDataVO(totalCount, dataList); 
  } 
} 

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

問題是：為什么開發(fā)工具不報(bào)編譯錯(cuò)誤啦?

問題分析

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

以前的寫法：

ArrayList list = new ArrayList(); 

現(xiàn)在的寫法：

ArrayList<String> list = new ArrayList<String>(); 

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

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

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

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

• 把 List 對(duì)象賦值給 List，命中了第一種情況;
• 把 PageDataVO 對(duì)象賦值給 PageDataVO，命中了第二種情況。

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

問題的根源就是：我們?cè)诔跏蓟?PageDataVO 對(duì)象時(shí)，沒有要求強(qiáng)制進(jìn)行類型檢查。

避坑方法

1)在初始化泛型對(duì)象時(shí)，推薦使用 diamond 語法

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

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

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

正例：

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

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

在初始化泛型對(duì)象時(shí)，推薦使用 diamond 語法，代碼如下：

return new PageDataVO<>(totalCount, dataList); 

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

Cannot infer type arguments for PageDataVO<> 

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

4、泛型屬性拷貝

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

問題現(xiàn)象

根據(jù)數(shù)據(jù)庫開發(fā)規(guī)范，數(shù)據(jù)庫表格必須包含 id，gmt_create，gmt_modified 三個(gè)字段。其中，id 這個(gè)字段，可能根據(jù)數(shù)據(jù)量不同，采用 int 或 long 類型。

首先，定義了一個(gè) BaseDO 基類：

/** 基礎(chǔ)DO類 */ 
@Getter 
@Setter 
@ToString 
public class BaseDO<T> { 
  private T id; 
  private Date gmtCreate; 
  private Date gmtModified;} 

針對(duì) user 表，定義了一個(gè) UserDO 類：

/** 用戶DO */ 
@Getter 
@Setter 
@ToString 
public static class UserDO extends BaseDO<Long> {     
  private String name; 
  private String description; 
} 

對(duì)于查詢接口，定義了一個(gè) UserVO 類：

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

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

/** 用戶服務(wù)類 */ 
@Service 
public class UserService {       
 
  /** 用戶DAO */       
  @Autowired       
  private UserDAO userDAO; 
 
    /** 查詢用戶 */       
    public List<UserVO> queryUser(UserQueryVO query) {             
      // 查詢用戶信息             
      List<UserDO> userDOList = userDAO.queryUser(query);             
      if (CollectionUtils.isEmpty()) {                   
          return Collections.emptyList();    
          } 
       
       // 轉(zhuǎn)化用戶列表           
       List<UserVO> userVOList = new ArrayList<>(userDOList.size()); 
           for (UserDO userDO : userDOList) {                 
             UserVO userVO = new UserVO();             
             BeanUtils.copyProperties(userDO, userVO);             
             userVOList.add(userVO);             
        } 
 
       // 返回用戶列表 
       return userVOList;       
     } 
} 

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

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

問題分析

通過 Debug 模式運(yùn)行，進(jìn)入到 BeanUtils.copyProperties 工具方法內(nèi)部，得到以下內(nèi)容：

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

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

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

避坑方法

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

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

2)如果需要拷貝的屬性較少，可以手動(dòng)編碼進(jìn)行屬性拷貝

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

5、Set 對(duì)象排重

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

問題現(xiàn)象

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

/** 城市輔助類 */ 
@Slf4j 
public class CityHelper { 
    /** 讀取城市 */ 
    public static Collection<City> readCities(String fileName) { 
        try (FileInputStream stream = new FileInputStream(fileName); 
            InputStreamReader reader = new InputStreamReader(stream, "GBK"); 
            CSVParser parser = new CSVParser(reader, CSVFormat.DEFAULT.withHeader())) { 
            Set<City> citySet = new HashSet<>(1024); 
            Iterator<CSVRecord> 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ù)重復(fù)，對(duì)讀取的城市數(shù)據(jù)進(jìn)行強(qiáng)制排重。

當(dāng)輸入文件內(nèi)容如下時(shí)：

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

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

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

但是，并沒有對(duì)城市“北京”進(jìn)行排重。

問題分析

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

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

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

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

那么，我們就重寫把 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); 
    } 
} 

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

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

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

避坑方法

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

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

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

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

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

Map<String, City> cityMap = new HashMap<>(1024); 
Iterator<CSVRecord> 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 方法的自定義類不應(yīng)該在 Set 中使用。

6、公有方法代理

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

問題現(xiàn)象

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

1)UserService.java

/** 用戶服務(wù)類 */ 
@Service 
public class UserService { 
    /** 超級(jí)用戶 */ 
    private User superUser; 
 
    /** 設(shè)置超級(jí)用戶 */ 
    public void setSuperUser(User superUser) { 
        this.superUser = superUser; 
    } 
 
    /** 獲取超級(jí)用戶 */ 
    public final User getSuperUser() { 
        return this.superUser; 
    } 
} 

2)CompanyService.java

/** 公司服務(wù)類 */ 
@Service 
public class CompanyService { 
    /** 公司DAO */ 
    @Autowired 
    private CompanyDAO companyDAO; 
    /** 用戶服務(wù) */ 
    @Autowired 
    private UserService userService; 
 
    /** 刪除公司 */ 
    public void deleteCompany(Long companyId, Long operatorId) { 
        // 設(shè)置超級(jí)用戶 
        userService.setSuperUser(new User(0L, "admin", "超級(jí)用戶")); 
 
        // 驗(yàn)證超級(jí)用戶 
        if (!Objects.equals(operatorId, userService.getSuperUser().getId())) { 
            throw new ExampleException("只有超級(jí)用戶才能刪除公司"); 
        } 
 
        // 刪除公司信息 
        companyDAO.delete(companyId, operatorId); 
    } 
} 

當(dāng)我們調(diào)用 CompanyService 的 deleteCompany 方法時(shí)，居然也拋出空指針異常 (NullPointerException)，因?yàn)檎{(diào)用 UserService 類的 getSuperUser 方法獲取的超級(jí)用戶為 null。但是，我們?cè)? CompanyService 類的 deleteCompany 方法中，每次都通過 UserService 類的 setSuperUser 方法強(qiáng)制指定了超級(jí)用戶，按道理通過 UserService 類的 getSuperUser 方法獲取到的超級(jí)用戶不應(yīng)該為 null。其實(shí)，這個(gè)問題也是由 AOP 代理導(dǎo)致的。

問題分析

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

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); 
        } 
    } 
    ...... 
} 

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

避坑方法

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

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

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

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

7、公有字段代理

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

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

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

問題現(xiàn)象

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

1)UserService.java

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

2)CompanyService.java

/** 公司服務(wù)類 */ 
@Service 
public class CompanyService { 
    /** 公司DAO */ 
    @Autowired 
    private CompanyDAO companyDAO; 
    /** 用戶服務(wù) */ 
    @Autowired 
    private UserService userService; 
 
    /** 刪除公司 */ 
    public void deleteCompany(Long companyId, Long operatorId) { 
        // 驗(yàn)證超級(jí)用戶 
        if (!Objects.equals(operatorId, userService.superUser.getId())) { 
            throw new ExampleException("只有超級(jí)用戶才能刪除公司"); 
        } 
 
        // 刪除公司信息 
        companyDAO.delete(companyId, operatorId); 
    } 
} 

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

問題分析

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

 

 

避坑方法

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

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

2)當(dāng)確定字段不可變時(shí)，可以定義為私有成員變量

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

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

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

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