前言

作為一名java開(kāi)發(fā)程序員，不知道大家有沒(méi)有遇到過(guò)一些匪夷所思的bug。這些錯(cuò)誤通常需要您幾個(gè)小時(shí)才能解決。當(dāng)你找到它們的時(shí)候，你可能會(huì)默默地罵自己是個(gè)傻瓜。是的，這些可笑的bug基本上都是你忽略了一些基礎(chǔ)知識(shí)造成的。其實(shí)都是很低級(jí)的錯(cuò)誤。今天，我總結(jié)一些常見(jiàn)的編碼錯(cuò)誤，然后給出解決方案。希望大家在日常編碼中能夠避免這樣的問(wèn)題。

1. 使用Objects.equals比較對(duì)象

這種方法相信大家并不陌生，甚至很多人都經(jīng)常使用。是JDK7提供的一種方法，可以快速實(shí)現(xiàn)對(duì)象的比較，有效避免煩人的空指針檢查。但是這種方法很容易用錯(cuò)，例如：

Long longValue = 123L;
System.out.println(longValue==123); //true
System.out.println(Objects.equals(longValue,123)); //false

為什么替換==為Objects.equals()會(huì)導(dǎo)致不同的結(jié)果？這是因?yàn)槭褂?code>==編譯器會(huì)得到封裝類型對(duì)應(yīng)的基本數(shù)據(jù)類型longValue，然后與這個(gè)基本數(shù)據(jù)類型進(jìn)行比較，相當(dāng)于編譯器會(huì)自動(dòng)將常量轉(zhuǎn)換為比較基本數(shù)據(jù)類型, 而不是包裝類型。

使用該Objects.equals()方法后，編譯器默認(rèn)常量的基本數(shù)據(jù)類型為int。下面是源碼Objects.equals()，其中a.equals(b)使用的是Long.equals()會(huì)判斷對(duì)象類型，因?yàn)榫幾g器已經(jīng)認(rèn)為常量是int類型，所以比較結(jié)果一定是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;
}

知道了原因，解決方法就很簡(jiǎn)單了。直接聲明常量的數(shù)據(jù)類型，如Objects.equals(longValue,123L)。其實(shí)如果邏輯嚴(yán)密，就不會(huì)出現(xiàn)上面的問(wèn)題。我們需要做的是保持良好的編碼習(xí)慣。

2. 日期格式錯(cuò)誤

在我們?nèi)粘５拈_(kāi)發(fā)中，經(jīng)常需要對(duì)日期進(jìn)行格式化，但是很多人使用的格式不對(duì)，導(dǎo)致出現(xiàn)意想不到的情況。請(qǐng)看下面的例子。

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。為什么？這是因?yàn)?nbsp;java 的DateTimeFormatter 模式YYYY和yyyy之間存在細(xì)微的差異。它們都代表一年，但是yyyy代表日歷年，而YYYY代表星期。這是一個(gè)細(xì)微的差異，僅會(huì)導(dǎo)致一年左右的變更問(wèn)題，因此您的代碼本可以一直正常運(yùn)行，而僅在新的一年中引發(fā)問(wèn)題。12月31日按周計(jì)算的年份是2022年，正確的方式應(yīng)該是使用yyyy-MM-dd格式化日期。

這個(gè)bug特別隱蔽。這在平時(shí)不會(huì)有問(wèn)題。它只會(huì)在新的一年到來(lái)時(shí)觸發(fā)。我公司就因?yàn)檫@個(gè)bug造成了生產(chǎn)事故。

3. 在 ThreadPool 中使用 ThreadLocal

如果創(chuàng)建一個(gè)ThreadLocal 變量，訪問(wèn)該變量的線程將創(chuàng)建一個(gè)線程局部變量。合理使用ThreadLocal可以避免線程安全問(wèn)題。

但是，如果在線程池中使用ThreadLocal ，就要小心了。您的代碼可能會(huì)產(chǎn)生意想不到的結(jié)果。舉個(gè)很簡(jiǎn)單的例子，假設(shè)我們有一個(gè)電商平臺(tái)，用戶購(gòu)買(mǎi)商品后需要發(fā)郵件確認(rèn)。

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來(lái)保存用戶信息，這里就會(huì)有一個(gè)隱藏的bug。因?yàn)槭褂昧司€程池，線程是可以復(fù)用的，所以在使用ThreadLocal獲取用戶信息的時(shí)候，很可能會(huì)誤獲取到別人的信息。您可以使用會(huì)話來(lái)解決這個(gè)問(wèn)題。

4. 使用HashSet去除重復(fù)數(shù)據(jù)

在編碼的時(shí)候，我們經(jīng)常會(huì)有去重的需求。一想到去重，很多人首先想到的就是用HashSet去重。但是，不小心使用 HashSet 可能會(huì)導(dǎo)致去重失敗。

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

細(xì)心的讀者應(yīng)該已經(jīng)猜到失敗的原因了。HashSet使用hashcode對(duì)哈希表進(jìn)行尋址，使用equals方法判斷對(duì)象是否相等。如果自定義對(duì)象沒(méi)有重寫(xiě)hashcode方法和equals方法，則默認(rèn)使用父對(duì)象的hashcode方法和equals方法。所以HashSet會(huì)認(rèn)為這是兩個(gè)不同的對(duì)象，所以導(dǎo)致去重失敗。

5. 線程池中的異常被吃掉

ExecutorService executorService = Executors.newFixedThreadPool(1);
executorService.submit(()->{
    //do something
    double result = 10/0;
});

上面的代碼模擬了一個(gè)線程池拋出異常的場(chǎng)景。我們真正的業(yè)務(wù)代碼要處理各種可能出現(xiàn)的情況，所以很有可能因?yàn)槟承┨囟ǖ脑蚨|發(fā)RuntimeException 。

但是如果沒(méi)有特殊處理，這個(gè)異常就會(huì)被線程池吃掉。這樣就會(huì)導(dǎo)出出現(xiàn)問(wèn)題你都不知道，這是很?chē)?yán)重的后果。因此，最好在線程池中try catch捕獲異常。

到此這篇關(guān)于Java開(kāi)發(fā)人員最常犯的5個(gè)錯(cuò)誤總結(jié)的文章就介紹到這了,更多相關(guān)Java開(kāi)發(fā)人員常犯的錯(cuò)誤內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論