K60 Pro官方停產(chǎn) 第三方瞬間漲價
雖然沒有官方宣布，但Redmi的一些高管也已經(jīng)透露了，Redmi K60 Pro已經(jīng)停產(chǎn)且不會補貨，這一切都是為了即將到來的K60 Ultra鋪路，屬于廠家的正常操作。但有意思的是該機在停產(chǎn)之后
經(jīng)常有些面試官會問，是否了解過 HashMap 在多線程環(huán)境下使用時可能會發(fā)生死循環(huán)，導致服務器 cpu 100% 的線上故障？
關(guān)于這個問題，很多年前，在淘寶內(nèi)網(wǎng)里就有很多的程序員發(fā)過這種帖子說一個CPU 被100%了，原因竟是多線程環(huán)境下使用 HashMap 造成的死循環(huán)，并且這個事發(fā)生了很多次。
雖然 Java 官方明確表示，在多線程環(huán)境下不推薦使用 HashMap，但是對于這種問題，小編其實也比較意外，如果不是深入的去了解 HashMap，都不知道有這樣的問題。
為什么會產(chǎn)生死循環(huán)呢？下面我們來還原一下問題的經(jīng)過。
在之前的集合系列文章中，我們了解到 HashMap 是一個哈希數(shù)組 + 鏈表的數(shù)據(jù)結(jié)構(gòu)，在實際的程序開發(fā)中，我們經(jīng)常會使用到 HashMap，如果對 HashMap 不是很了解，大家可以看小編之前寫的《深入淺出分析 HashMap 》一文。
HashMap 是一個非線程安全的集合操作類，如果我們的程序操作是單線程的，那么一切都沒問題。當我們的程序是多線程操作 HashMap 類時，那么問題就來了，我們一起來復現(xiàn)一下。
測試代碼，如下：
使用了4個線程來向 HashMap 中添加元素，可能一次運行不一定有效果，可以反復運行幾次！
控制臺輸出結(jié)果：
可以清晰的看到，在遍歷 map 的內(nèi)容時，已經(jīng)死循環(huán)了！
再來看看，活動監(jiān)視器，結(jié)果如下：
cpu 的使用率，直接接近 200%！
接下來我們?nèi)ゲ榭聪?java 中剛剛運行的 HashThreadTest 類堆棧情況：
可以看到，HashMap 的擴容操作導致了死循環(huán)！
通過測試，我們發(fā)現(xiàn) HashMap 在多線程環(huán)境下進行操作，的確會產(chǎn)生死循環(huán)，并且會導致 CPU 100%！
這是為什么呢？我們一起來閱讀一下源碼！
注意注意，小編在進行測試的時候，使用的是 JDK1.7 的版本！
如果你使用 JDK1.8 的版本，不好意思，不一定能復現(xiàn)這個問題！因為 JDK1.8 已經(jīng)修復了這個問題，但是依然不建議在多線程環(huán)境下使用 HashMap！
我們繼續(xù)來看看為什么使用 JDK1.7 會出現(xiàn)這個問題！
既然是 put 階段造成的數(shù)據(jù)問題，我們不妨一起來看看 HashMap 的 put 過程！
HashMap 的 put 源碼實現(xiàn)如下：
接著我們來看看addEntry()方法，將元素插入到數(shù)組中，并且檢查容量是否超標，源碼實現(xiàn)如下：
上面例子中，我們初始化的時候給定的容量是 2，所以在添加元素時必定會擴容！如果超出閥值，就進行擴容處理，創(chuàng)建一個更大容量的 hash 表，然后把從老的 Hash 表中遷移到新的 Hash 表中，源碼如下：
將舊 hash 表中的元素復制到新的 hash 表中，源碼如下：
整個 put 過程，大致可以分如下幾個步驟：
好了，這個過程基本上沒啥問題。
我們再來演示一下擴容中重新計算元素 hash 的過程！
假設在單線程環(huán)境下，我們初始化的時候，給定的數(shù)組容量是2，分別添加3個元素，內(nèi)容如下：
源碼如下：
添加完成之后，數(shù)組就會進行擴容處理，擴容后 hash 的容量為原來的2倍，擴容操作流程如下：
在單線程環(huán)境下，一切看起來都很正常，擴容過程也相當順利。接下來我們看下并發(fā)情況下的擴容。
假設我們有兩個線程，來分別添加3個元素。
線程二執(zhí)行完添加任務之后，在準備將舊元素遷移到新元素的時候，也就是準備 rehash 時，突然被 CPU 掛起，此時阻塞在如下圖中的第57行，不再往下執(zhí)行！而線程一繼續(xù)執(zhí)行直到擴容完成。
2個線程此時的執(zhí)行結(jié)果，內(nèi)容如下：
接著線程二被喚醒，繼續(xù)回到第57行執(zhí)行。
此時注意了，我們來詳細的分析一下這個過程！
第一次循環(huán)過程如下：
循環(huán)結(jié)果如下，e={key:5,value:C}，滿足while()循環(huán)條件，接著繼續(xù)！
第二次循環(huán)過程如下：
循環(huán)結(jié)果如下，e={key:3,value:A}，滿足while()循環(huán)條件，接著繼續(xù)！
第三次循環(huán)過程如下：
循環(huán)結(jié)果如下，e=null，while()程序不在循環(huán)！
綜合線程1、線程2執(zhí)行結(jié)果，最終 hashMap 的存儲結(jié)果，如下圖：
可以很清晰的看到，鏈表發(fā)生死循環(huán)了！
于是，當我們在遍歷 hashMap 鏈表內(nèi)容的時候，就會出現(xiàn)上文中問題復現(xiàn)的場景，死循環(huán)式的輸出相同的內(nèi)容，CPU 直接飆到200%了！
對于這種問題，當初有人上報到 SUN 公司，但是 SUN 不認為這是一個問題，因為 HashMap 本來就不支持并發(fā)操作！
所以，不建議在多線程環(huán)境下使用 HashMap，那如果要在多線程環(huán)境下使用 map 操作類，該怎么辦呢？
辦法肯定是有的，如果大家想在多線程場景下使用 HashMap，有兩種解決辦法：
本文鏈接：http://m.www897cc.com/showinfo-26-90663-0.html阿里二面：聽說過 HashMap 會導致CPU飆升100%嗎？
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 敏捷的數(shù)據(jù)工程實踐
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號