作為一名java開發程式設計師,不知道大家有沒有遇到過一些匪夷所思的bug。這些錯誤通常需要您幾個小時才能解決。當你找到它們的時候,你可能會默默地罵自己是個傻瓜。是的,這些可笑的bug基本上都是你忽略了一些基礎知識造成的。其實都是很低階的錯誤。今天,我總結一些常見的編碼錯誤,然後給出解決方案。希望大家在日常編碼中能夠避免這樣的問題。
歡迎關注微信公眾號「JAVA旭陽」交流和學習
這種方法相信大家並不陌生,甚至很多人都經常使用。是JDK7提供的一種方法,可以快速實現物件的比較,有效避免煩人的空指標檢查。但是這種方法很容易用錯,例如:
Long longValue = 123L;
System.out.println(longValue==123); //true
System.out.println(Objects.equals(longValue,123)); //false
為什麼替換==
為Objects.equals()
會導致不同的結果?這是因為使用==
編譯器會得到封裝型別對應的基本資料型別longValue
,然後與這個基本資料型別進行比較,相當於編譯器會自動將常數轉換為比較基本資料型別, 而不是包裝型別。
使用該Objects.equals()
方法後,編譯器預設常數的基本資料型別為int
。下面是原始碼Objects.equals()
,其中a.equals(b)
使用的是Long.equals()
會判斷物件型別,因為編譯器已經認為常數是int
型別,所以比較結果一定是false
。
public static boolean equals(Object a, Object b) {
return (a == b) || (a != null && a.equals(b));
}
public boolean equals(Object obj) {
if (obj instanceof Long) {
return value == ((Long)obj).longValue();
}
return false;
}
知道了原因,解決方法就很簡單了。直接宣告常數的資料型別,如Objects.equals(longValue,123L)
。其實如果邏輯嚴密,就不會出現上面的問題。我們需要做的是保持良好的編碼習慣。
在我們日常的開發中,經常需要對日期進行格式化,但是很多人使用的格式不對,導致出現意想不到的情況。請看下面的例子。
Instant instant = Instant.parse("2021-12-31T00:00:00.00Z");
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("YYYY-MM-dd HH:mm:ss")
.withZone(ZoneId.systemDefault());
System.out.println(formatter.format(instant));//2022-12-31 08:00:00
以上用於YYYY-MM-dd
格式化, 年從2021
變成了 2022
。為什麼?這是因為 java
的DateTimeFormatter
模式YYYY
和yyyy
之間存在細微的差異。它們都代表一年,但是yyyy
代表日曆年,而YYYY
代表星期。這是一個細微的差異,僅會導致一年左右的變更問題,因此您的程式碼本可以一直正常執行,而僅在新的一年中引發問題。12月31日按周計算的年份是2022年,正確的方式應該是使用yyyy-MM-dd
格式化日期。
這個bug
特別隱蔽。這在平時不會有問題。它只會在新的一年到來時觸發。我公司就因為這個bug造成了生產事故。
如果建立一個ThreadLocal
變數,存取該變數的執行緒將建立一個執行緒區域性變數。合理使用ThreadLocal
可以避免執行緒安全問題。
但是,如果線上程池中使用ThreadLocal
,就要小心了。您的程式碼可能會產生意想不到的結果。舉個很簡單的例子,假設我們有一個電商平臺,使用者購買商品後需要發郵件確認。
private ThreadLocal<User> currentUser = ThreadLocal.withInitial(() -> null);
private ExecutorService executorService = Executors.newFixedThreadPool(4);
public void executor() {
executorService.submit(()->{
User user = currentUser.get();
Integer userId = user.getId();
sendEmail(userId);
});
}
如果我們使用ThreadLocal
來儲存使用者資訊,這裡就會有一個隱藏的bug。因為使用了執行緒池,執行緒是可以複用的,所以在使用ThreadLocal
獲取使用者資訊的時候,很可能會誤獲取到別人的資訊。您可以使用對談來解決這個問題。
在編碼的時候,我們經常會有去重的需求。一想到去重,很多人首先想到的就是用HashSet
去重。但是,不小心使用 HashSet
可能會導致去重失敗。
User user1 = new User();
user1.setUsername("test");
User user2 = new User();
user2.setUsername("test");
List<User> users = Arrays.asList(user1, user2);
HashSet<User> sets = new HashSet<>(users);
System.out.println(sets.size());// the size is 2
細心的讀者應該已經猜到失敗的原因了。HashSet
使用hashcode
對雜湊表進行定址,使用equals
方法判斷物件是否相等。如果自定義物件沒有重寫hashcode
方法和equals方法,則預設使用父物件的hashcode
方法和equals
方法。所以HashSet
會認為這是兩個不同的物件,所以導致去重失敗。
ExecutorService executorService = Executors.newFixedThreadPool(1);
executorService.submit(()->{
//do something
double result = 10/0;
});
上面的程式碼模擬了一個執行緒池丟擲異常的場景。我們真正的業務程式碼要處理各種可能出現的情況,所以很有可能因為某些特定的原因而觸發RuntimeException
。
但是如果沒有特殊處理,這個異常就會被執行緒池吃掉。這樣就會匯出出現問題你都不知道,這是很嚴重的後果。因此,最好線上程池中try catch
捕獲異常。
本文總結了在開發過程中很容易犯的5個錯誤,希望大家養成良好的編碼習慣。
歡迎關注微信公眾號「JAVA旭陽」交流和學習
更多學習資料請移步:程式設計師成神之路
本文來自部落格園,作者:JAVA旭陽,轉載請註明原文連結:https://www.cnblogs.com/alvinscript/p/17011307.html