90%的Java開發(fā)人員都會(huì)犯的5個(gè)錯(cuò)誤

前言

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

1. 使用Objects.equals比較對象

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

Long longValue = 123L;
System.out.println(longValue==123); //true
System.out.println(Objects.equals(longValue,123)); //false
復(fù)制代碼
image.gif

為什么替換==Objects.equals()會(huì)導(dǎo)致不同的結(jié)果祥绞?這是因?yàn)槭褂?code>==編譯器會(huì)得到封裝類型對應(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ì)判斷對象類型缆瓣,因?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;
}
復(fù)制代碼
image.gif

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

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

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

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
復(fù)制代碼
image.gif

以上用于YYYY-MM-dd格式化, 年從2021 變成了 2022巍举。為什么?這是因?yàn)?javaDateTimeFormatter 模式YYYYyyyy之間存在細(xì)微的差異凝垛。它們都代表一年懊悯,但是yyyy代表日歷年,而YYYY代表星期梦皮。這是一個(gè)細(xì)微的差異炭分,僅會(huì)導(dǎo)致一年左右的變更問題,因此您的代碼本可以一直正常運(yùn)行剑肯,而僅在新的一年中引發(fā)問題捧毛。12月31日按周計(jì)算的年份是2022年,正確的方式應(yīng)該是使用yyyy-MM-dd格式化日期退子。

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

3. 在 ThreadPool 中使用 ThreadLocal

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

但是,如果在線程池中使用ThreadLocal 惜犀,就要小心了铛碑。您的代碼可能會(huì)產(chǎn)生意想不到的結(jié)果。舉個(gè)很簡單的例子虽界,假設(shè)我們有一個(gè)電商平臺(tá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);
    });
}
復(fù)制代碼
image.gif

如果我們使用ThreadLocal來保存用戶信息莉御,這里就會(huì)有一個(gè)隱藏的bug撇吞。因?yàn)槭褂昧司€程池,線程是可以復(fù)用的礁叔,所以在使用ThreadLocal獲取用戶信息的時(shí)候牍颈,很可能會(huì)誤獲取到別人的信息。您可以使用會(huì)話來解決這個(gè)問題琅关。

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
復(fù)制代碼
image.gif

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

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

ExecutorService executorService = Executors.newFixedThreadPool(1);
executorService.submit(()->{
    //do something
    double result = 10/0;
});
復(fù)制代碼
image.gif

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

但是如果沒有特殊處理,這個(gè)異常就會(huì)被線程池吃掉禀晓。這樣就會(huì)導(dǎo)出出現(xiàn)問題你都不知道精续,這是很嚴(yán)重的后果。因此粹懒,最好在線程池中try catch捕獲異常重付。

總結(jié)

本文總結(jié)了在開發(fā)過程中很容易犯的5個(gè)錯(cuò)誤,希望大家養(yǎng)成良好的編碼習(xí)慣凫乖。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末确垫,一起剝皮案震驚了整個(gè)濱河市弓颈,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌删掀,老刑警劉巖翔冀,帶你破解...
    沈念sama閱讀 219,039評論 6 508
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異披泪,居然都是意外死亡纤子,警方通過查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,426評論 3 395
  • 文/潘曉璐 我一進(jìn)店門款票,熙熙樓的掌柜王于貴愁眉苦臉地迎上來控硼,“玉大人,你說我怎么就攤上這事徽职∠笥保” “怎么了?”我有些...
    開封第一講書人閱讀 165,417評論 0 356
  • 文/不壞的土叔 我叫張陵姆钉,是天一觀的道長说订。 經(jīng)常有香客問我,道長潮瓶,這世上最難降的妖魔是什么陶冷? 我笑而不...
    開封第一講書人閱讀 58,868評論 1 295
  • 正文 為了忘掉前任,我火速辦了婚禮毯辅,結(jié)果婚禮上埂伦,老公的妹妹穿的比我還像新娘。我一直安慰自己思恐,他們只是感情好沾谜,可當(dāng)我...
    茶點(diǎn)故事閱讀 67,892評論 6 392
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著胀莹,像睡著了一般基跑。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上描焰,一...
    開封第一講書人閱讀 51,692評論 1 305
  • 那天媳否,我揣著相機(jī)與錄音,去河邊找鬼荆秦。 笑死篱竭,一個(gè)胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的步绸。 我是一名探鬼主播掺逼,決...
    沈念sama閱讀 40,416評論 3 419
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼靡努!你這毒婦竟也來了坪圾?” 一聲冷哼從身側(cè)響起晓折,我...
    開封第一講書人閱讀 39,326評論 0 276
  • 序言:老撾萬榮一對情侶失蹤惑朦,失蹤者是張志新(化名)和其女友劉穎兽泄,沒想到半個(gè)月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體漾月,經(jīng)...
    沈念sama閱讀 45,782評論 1 316
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡病梢,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 37,957評論 3 337
  • 正文 我和宋清朗相戀三年,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了梁肿。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片蜓陌。...
    茶點(diǎn)故事閱讀 40,102評論 1 350
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡,死狀恐怖吩蔑,靈堂內(nèi)的尸體忽然破棺而出钮热,到底是詐尸還是另有隱情,我是刑警寧澤烛芬,帶...
    沈念sama閱讀 35,790評論 5 346
  • 正文 年R本政府宣布隧期,位于F島的核電站,受9級(jí)特大地震影響赘娄,放射性物質(zhì)發(fā)生泄漏仆潮。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,442評論 3 331
  • 文/蒙蒙 一遣臼、第九天 我趴在偏房一處隱蔽的房頂上張望性置。 院中可真熱鬧,春花似錦揍堰、人聲如沸鹏浅。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,996評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽隐砸。三九已至,卻和暖如春西采,著一層夾襖步出監(jiān)牢的瞬間凰萨,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,113評論 1 272
  • 我被黑心中介騙來泰國打工械馆, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留胖眷,地道東北人。 一個(gè)月前我還...
    沈念sama閱讀 48,332評論 3 373
  • 正文 我出身青樓霹崎,卻偏偏與公主長得像珊搀,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個(gè)殘疾皇子尾菇,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 45,044評論 2 355

推薦閱讀更多精彩內(nèi)容