前言
中國有句老話叫"事不過三"，指一個人犯了同樣的錯誤，一次兩次還可以原諒，再多就不可原諒了。寫代碼也是如此，同一個代碼“坑”，踩第一次叫"長了經驗"，踩第二次叫"加深印象"，踩第三次叫"不長記性"，踩三次以上就叫"不可救藥"。在本文中，筆者總結了一些 Java 坑，描述了問題現象，進行了問題分析，給出了避坑方法。希望大家在日常工作中，遇到了這類 Java 坑，能夠提前避讓開來。
1 對象比較方法
JDK 1.7 提供的 Objects.equals 方法，非常友善地實作了對象的比較，有效地避免了繁瑣的空指針檢查。
問題現象
在 JDK1.7 之前，在判斷一個短整型、整型、長整型包裝資料類型與常量是否相等時，我們一般這樣寫：
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
方法，并推薦使用函數式程式設計，更改代碼如下：
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
方法就會導緻輸出結果不一樣？
問題分析
通過反編譯第一段代碼，我們得到語句
System.out.println(shortValue == 12345);
的位元組碼指令如下：
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] 原來，編譯器會判斷包裝資料類型對應的基本資料類型，并采用這個基本資料類型的指令進行比較（比如上面位元組碼指令中的 sipush 和 if_icmpne 等），相當于編譯器自動對常量進行了資料類型的強制轉化。
為什麼采用 Objects.equals 方法後，編譯器不自動對常量進行資料類型的強制轉化？通過反編譯第二段代碼，我們得到語句
System.out.println(Objects.equals(shortValue, 12345));
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] 原來，編譯器根據字面意思，認為常量
12345
預設基本資料類型是 int，是以會自動轉化為包裝資料類型 Integer。
在 Java 語言中，整數的預設資料類型是 int，小數的預設資料類型是 double。
通過分析
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）保持良好的編碼習慣，避免資料類型的自動轉化
為了避免資料類型自動轉化，更科學的寫法是直接聲明常量為對應的基本資料類型。
第一段代碼可以這樣寫：
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）借助開發工具或插件，及早地發現資料類型不比對問題
在 Eclipse 的問題視窗中，我們會看到這樣的提示：
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）進行正常性單元測試，盡量把問題發現在研發階段
“勿以善小而不為”，不要因為改動很小就不需要進行單元測試了，往往 Bug 都出現在自己過度自信的代碼中。像這種問題，隻要進行一次單元測試，是完全可以發現問題的。
注意：進行必要單元測試，适用于以下所有案例，是以下文不再累述。
2 三元表達式拆包
三元表達式是 Java 編碼中的一個固定文法格式：
條件表達式？表達式1：表達式2
三元表達式的邏輯為：如果條件表達式成立，則執行表達式 1，否則執行表達式 2。
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，按道理沒有任何問題，為什麼會抛出空指針異常？
通過反編譯代碼，我們得到語句：
Double result = condition ? value1 * value2 : value3; 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 對象 value 3 到操作數棧中；在第 10 行，調用 Double 對象 value 3 的 doubleValue 方法。這個時候，由于 value 3 是空對象 null，調用 doubleValue 方法必然抛出抛出空指針異常。但是，為什麼要把空對象 value 3 轉化為基礎資料類型 double 呢？
查閱相關資料，得到三元表達式的類型轉化規則：
1）若兩個表達式類型相同，傳回值類型為該類型；
2）若兩個表達式類型不同，但類型不可轉換，傳回值類型為 Object 類型；
3）若兩個表達式類型不同，但類型可以轉化，先把包裝資料類型轉化為基本資料類型，然後按照基本資料類型的轉換規則 （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 語句代替。改寫代碼如下：
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 泛型對象指派
Java 泛型是 JDK 1.5 中引入的一個新特性，其本質是參數化類型，即把資料類型做為一個參數使用。
在做使用者資料分頁查詢時，因為筆誤編寫了如下代碼：
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);
}
} 以上代碼沒有任何編譯問題，但是卻把 UserDO 中一些涉密字段傳回給前端。細心的讀者可能已經發現了，在 UserService 類的 queryUser 方法的語句
return new PageDataVO(totalCount, dataList);
中，我們把 List 對象 dataList 指派給了 PageDataVO 的 List 字段 dataList。
問題是：為什麼開發工具不報編譯錯誤啦？
由于曆史原因，參數化類型和原始類型需要相容。我們以 ArrayList 舉例子，來看看如何相容的。
以前的寫法：
ArrayList list = new ArrayList(); 現在的寫法：
ArrayList<String> list = new ArrayList<String>(); 考慮到與以前的代碼相容，各種對象引用之間傳值，必然會出現以下的情況：
// 第一種情況
ArrayList list1 = new ArrayList<String>();
// 第二種情況
ArrayList<String> list2 = new ArrayList(); 是以，Java 編譯器對以上兩種類型進行了相容，不會出現編譯錯誤，但會出現編譯告警。但是，我的開發工具在編譯時真沒出現過告警。
再來分析我們遇到的問題，實際上同時命中了兩種情況：
1）把 List 對象指派給 List，命中了第一種情況；
2）把 PageDataVO 對象指派給 PageDataVO，命中了第二種情況。
最終的效果就是：我們神奇地把 List 對象指派給了 List。
問題的根源就是：我們在初始化 PageDataVO 對象時，沒有要求強制進行類型檢查。
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 對象轉化為 List 對象了。
4 泛型屬性拷貝
Spring 的 BeanUtils.copyProperties 方法，是一個很好用的屬性拷貝工具方法。
根據資料庫開發規範，資料庫表格必須包含 id，gmt_create，gmt_modified 三個字段。其中，id 這個字段，可能根據資料量不同，采用 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 static 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"},...] 通過 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())) {
... // 指派相關代碼
} 1）不要盲目地相信第三方工具包，任何工具包都有可能存在問題
在 Java 中，存在很多第三方工具包，比如：Apache 的 commons-lang3、commons-collections，Google 的 guava……都是很好用的第三方工具包。但是，不要盲目地相信第三方工具包，任何工具包都有可能存在問題。
2）如果需要拷貝的屬性較少，可以手動編碼進行屬性拷貝
用 BeanUtils.copyProperties 反射拷貝屬性，主要優點是節省了代碼量，主要缺點是導緻程式性能下降。是以，如果需要拷貝的屬性較少，可以手動編碼進行屬性拷貝。
5 Set 對象排重
在 Java 語言中，Set 資料結構可以用于對象排重，常見的 Set 類有 HashSet、LinkedHashSet 等。
編寫了一個城市輔助類，從 CSV 檔案中讀取城市資料：
/** 城市輔助類 */
@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 資料結構，目的是為了避免城市資料重複，對讀取的城市資料進行強制排重。
當輸入檔案内容如下時：
編碼,名稱
010,北京
020,廣州
010,北京 解析後的 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 方法。其實作如下：
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":"廣州"}] 結果正确，已經對城市“北京”進行排重。
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 方法，這是由繼承機制限制的。
這裡舉例一個簡單的例子，隻有超級使用者才有删除公司的權限，并且所有服務函數被 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);
}
} 當我們調用 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, 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 的問題。
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 動态代理了，于是一行代碼引起了一場“血案”。
仍然使用上章的例子，但是把擷取、設定方法删除，定義了一個公有字段。例子代碼如下：
/** 使用者服務類 */
@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);
}
} 當我們調用 CompanyService 的 deleteCompany 方法時，居然抛出空指針異常 （NullPointerException）。經過調試列印，發現是 UserService 的 superUser 變量為 null。如果把代理删除，就不會出現空指針異常，說明這個問題是由 AOP 代理導緻的。
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 坑。