那些年，我們踩過的 Java 坑

前言

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

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

1.對象比較方法

JDK1.7提供的Objects.equals方法，非常友善地實作了對象的比較，有效地避免了繁瑣的空指針檢查。

1.1.問題現象

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

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方法，并推薦使用函數式程式設計，更改代碼如下：

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方法會導緻輸出結果不一樣？

1.2.問題分析

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

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]           

原來，編譯器會判斷包裝資料類型對應的基本資料類型，并采用這個基本資料類型的指令進行比較（比如上面位元組碼指令中的sipush和if_icmpne等），相當于編譯器自動對常量進行了資料類型的強制轉化。

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

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]           

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

在Java語言中，整數的預設資料類型是int，小數的預設資料類型是double。

下面來分析一下Objects.equals方法的代碼實作：

Objects.equals方法的代碼實作為：

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

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

Short.equals方法的代碼實作為：

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

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

1.3.避坑方法

(1)保持良好的編碼習慣，避免資料類型的自動轉化

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

第一段代碼可以這樣寫：

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)借助開發工具或插件，及早地發現資料類型不比對問題

在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)進行正常性單元測試，盡量把問題發現在研發階段

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

2.三元表達式拆包

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

2.1.問題現象

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;"的位元組碼指令如下：

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到操作數棧中；在第35行，調用Double對象value3的doubleValue方法。這個時候，由于value3是空對象null，調用doubleValue方法必然抛出抛出空指針異常。但是，為什麼要把空對象value3轉化為基礎資料類型double？

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

1. 若兩個表達式類型相同，傳回值類型為該類型；
2. 若兩個表達式類型不同，但類型不可轉換，傳回值類型為Object類型；
3. 若兩個表達式類型不同，但類型可以轉化，先把包裝資料類型轉化為基本資料類型，然後按照基本資料類型的轉換規則（byte

根據規則分析，表達式1（value1 * value2）計算後傳回基礎資料類型double，表達式2（value3）傳回包裝資料類型Double，根據三元表達式的類型轉化規則判斷，最終的傳回類型為基礎資料類型double。是以，當條件表達式condition等于false時，需要把空對象value3轉化為基礎資料類型double，于是就調用了value3的doubleValue方法抛出了空指針異常。

可以用以下案例驗證三元表達式的類型轉化規則：

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語句代替

如果三元表達式中有算術計算和包裝資料類型，可以考慮利用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)盡量使用基本資料類型，避免資料類型的自動轉化

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

(3)進行覆寫性單元測試，盡量把問題發現在研發階段

像這種問題，隻要編寫一些單元測試用例，進行一些覆寫性測試，是完全可以提前發現的。

3.泛型對象指派

Java泛型是JDK1.5中引入的一個新特性，其本質是參數化類型，即把資料類型做為一個參數使用。

3.1.問題現象

在做使用者資料分頁查詢時，因為筆誤編寫了如下代碼：

(1)PageDataVO.java：

/** 分頁資料VO類 */
@Getter
@Setter
@ToString
@NoArgsConstructor
@AllArgsConstructor
public class PageDataVO<T> {
    /** 總共數量 */
    private Long totalCount;
    /** 資料清單 */
    private List<T> dataList;
}           

(2)UserDAO.java：

/** 使用者DAO接口 */
@Mapper
public interface UserDAO {
    /** 統計使用者數量 */
    public Long countUser(@Param("query") UserQueryVO query);
    /** 查詢使用者資訊 */
    public List<UserDO> queryUser(@Param("query") UserQueryVO query);
}           

(3)UserService.java：

/** 使用者服務類 */
@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);
    }
}           

(4)UserController.java：

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

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

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

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

3.2.問題分析

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

以前的寫法：

ArrayList list = new ArrayList();           

現在的寫法：

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

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

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

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

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

1. 把List<UserDO>對象指派給List，命中了第一種情況；
2. 把PageDataVO對象指派給PageDataVO<UserVO>，命中了第二種情況。

最終的效果就是：我們神奇地把List<UserDO>對象指派給了List<UserVO>。

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

3.3.避坑方法

(1)在初始化泛型對象時，推薦使用diamond文法

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

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

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

正例：

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

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

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

return new PageDataVO<>(totalCount, dataList);            

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

Cannot infer type arguments for PageDataVO<>           

于是，我們就知道忘了把List<UserDO>對象轉化為List<UserVO>對象了。

(2)在進行單元測試時，需要對比資料内容

在進行單元測試時，運作正常是一個名額，但資料正确才是更重要的名額。

4.泛型屬性拷貝

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

4.1.問題現象

根據資料庫開發規範，資料庫表格必須包含id，gmt_create，gmt_modified三個字段。其中，id這個字段，可能根據資料量不同，采用int或long類型（注意：阿裡規範要求必須是long類型，這裡為了舉例說明，允許為int或long類型）。

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

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

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

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

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

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

實作查詢使用者服務接口，實作代碼如下：

/** 使用者服務類 */
@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();
        }

        // 轉化使用者清單
        List<UserVO> userVOList = new ArrayList<>(userDOList.size());
        for (UserDO userDO : userDOList) {
            UserVO userVO = new UserVO();
            BeanUtils.copyProperties(userDO, userVO);
            userVOList.add(userVO);
        }

        // 傳回使用者清單
        return userVOList;
    }
}           

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

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

4.2.問題分析

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

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

經過測試，上面代碼傳回結果正常，使用者ID的值成功傳回。

那麼，就是BeanUtils.copyProperties工具方法的問題了。用Debug模式運作，進入到BeanUtils.copyProperties工具方法内部，得到以下資料：

原來，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())) {
   ... // 指派相關代碼
}           

4.3.避坑方法

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

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

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

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

(3)一定要進行單元測試，一定要對比資料内容

在編寫完代碼後，一定要進行單元測試，一定要對比資料内容。切莫想當然地認為：工具包很成熟、代碼也很簡單，不可能出現問題。

5.Set對象排重

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

5.1.問題現象

編寫了一個城市輔助類，從CSV檔案中讀取城市資料：

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

    /** 讀取城市 */
    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資料結構，目的是為了避免城市資料重複，對讀取的城市資料進行強制排重。

當輸入檔案内容如下時：

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

解析後的JSON結果如下：

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

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

5.2.問題分析

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

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

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

可以看出：Object類的hashCode方法是一個本地方法，傳回的是對象位址；Object類的equals方法隻比較對象是否相等。是以，對于兩條完全一樣的北京資料，由于在解析時初始化了不同的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結果如下：

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

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

5.3.避坑方法

(1)當确定資料唯一時，可以使用List代替Set

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

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

(2)當确定資料不唯一時，可以使用Map代替Set

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

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語言規範，重寫hashCode方法和equals方法

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

6.公有方法代理

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

6.1.問題現象

這裡舉例一個簡單的例子，隻有超級使用者才有删除公司的權限，并且所有服務函數被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 {
    /** 環繞方法 */
    @Around("execution(* org.changyi.springboot.service..*.*(..))")
    public Object around(ProceedingJoinPoint joinPoint) {
        try {
            log.info("開始調用服務方法...");
            return joinPoint.proceed();
        } catch (Throwable e) {
            log.error(e.getMessage(), e);
            throw new ExampleException(e.getMessage(), e);
        }
    }
}           

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

6.2.問題分析

使用SpringCGLIB代理類時，Spring會建立一個名為

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方法。是以，當我們調用setSuperUser方法時，設定的是原始對象執行個體的superUser字段值；而當我們調用getSuperUser方法時，擷取的是代理對象執行個體的superUser字段值。如果把這兩個方法的final修飾符互換，同樣存在擷取超級使用者為null的問題。

6.3.避坑方法

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

嚴格遵循CGLIB代理規範，被代理的類和方法不要加final修飾符，避免動态代理操作對象執行個體不同（原始對象執行個體和代理對象執行個體），進而導緻資料不一緻或空指針問題。

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

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

7.公有字段代理

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

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

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

7.1.問題現象

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

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

/** 公司服務類 */
@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);
    }
}           

同上一章AopConfiguration.java。

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

7.2.問題分析

UserService$$EnhancerBySpringCGLIB$$????????

的代理類。這個代理類繼承了UserService類，并覆寫了UserService類中的所有非final的public的方法。但是，這個代理類并不調用super基類的方法；相反，它會建立的一個成員userService并指向原始的UserService類對象執行個體。現在，記憶體中存在兩個對象執行個體：一個是原始的UserService對象執行個體，另一個指向UserService的代理對象執行個體。這個代理類隻是一個虛拟代理，它繼承了UserService類，并且具有與UserService相同的字段，但是它從來不會去初始化和使用它們。是以，一但通過這個代理類對象執行個體擷取公有成員變量時，将傳回一個預設值null。

7.3.避坑方法

(1)當确定字段不可變時，可以定義為公有靜态常量

當确定字段不可變時，可以定義為公有靜态常量，并用類名稱+字段名稱通路。類名稱+字段名稱通路公有靜态常量，與類執行個體的動态代理無關。

/** 使用者服務類 */
@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)當确定字段不可變時，可以定義為私有成員變量

當确定字段不可變時，可以定義為私有成員變量，提供一個公有方法擷取該變量值。當該類執行個體被動态代理時，代理方法會調用被代理方法，進而傳回被代理類的成員變量值。

/** 使用者服務類 */
@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編碼規範，不要定義公有成員變量

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

(1)JavaBean類必須是一個公共類，并将其通路屬性設定為public，如：public class User{......}

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

(3)一個JavaBean類不應有公共執行個體變量，類變量都為private，如：private Integer id;

(4)屬性應該通過一組getter/setter方法來通路。

後記

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

作者資訊：陳昌毅，花名常意，高德地圖技術專家，2018 年加入阿裡巴巴，一直從事地圖資料采集的相關工作。