你是否聽說過 HashMap 在多線程環境下操作可能會導致程序死循環?

作者:炸雞可樂
原文出處:www.pzblog.cn

一、問題描述

經常有些面試官會問,是否瞭解過 HashMap 在多線程環境下使用時可能會發生死循環,導致服務器 cpu 100% 的線上故障?

關於這個問題,很多年前,在淘寶內網裏就有很多的程序員發過這種帖子說一個CPU 被100%了,原因竟是多線程環境下使用 HashMap 造成的死循環,並且這個事發生了很多次。

雖然 Java 官方明確表示,在多線程環境下不推薦使用 HashMap,但是對於這種問題,小編其實也比較意外,如果不是深入的去了解 HashMap,都不知道有這樣的問題。

爲什麼會產生死循環呢?下面我們來還原一下問題的經過。

二、問題重現

在之前的集合系列文章中,我們瞭解到 HashMap 是一個哈希數組 + 鏈表的數據結構,在實際的程序開發中,我們經常會使用到 HashMap,如果對 HashMap 不是很瞭解,大家可以看小編之前寫的《深入淺出分析 HashMap 》一文。

HashMap 是一個非線程安全的集合操作類,如果我們的程序操作是單線程的,那麼一切都沒問題。當我們的程序是多線程操作 HashMap 類時,那麼問題就來了,我們一起來複現一下。

測試代碼,如下:

使用了4個線程來向 HashMap 中添加元素,可能一次運行不一定有效果,可以反覆運行幾次!

控制檯輸出結果:

可以清晰的看到,在遍歷 map 的內容時,已經死循環了!

再來看看,活動監視器,結果如下:

cpu 的使用率,直接接近 200%!

接下來我們去查看下 java 中剛剛運行的 HashThreadTest 類堆棧情況:

可以看到,HashMap 的擴容操作導致了死循環!

通過測試,我們發現 HashMap 在多線程環境下進行操作,的確會產生死循環,並且會導致 CPU 100%!

這是爲什麼呢?我們一起來閱讀一下源碼!

三、源碼閱讀

注意注意,小編在進行測試的時候,使用的是 JDK1.7 的版本!

如果你使用 JDK1.8 的版本,不好意思,不一定能復現這個問題!因爲 JDK1.8 已經修復了這個問題,但是依然不建議在多線程環境下使用 HashMap!

我們繼續來看看爲什麼使用 JDK1.7 會出現這個問題!

既然是 put 階段造成的數據問題,我們不妨一起來看看 HashMap 的 put 過程!

3.1、HashMap 添加過程

HashMap 的 put 源碼實現如下:

接着我們來看看addEntry()方法,將元素插入到數組中,並且檢查容量是否超標,源碼實現如下:

上面例子中,我們初始化的時候給定的容量是 2,所以在添加元素時必定會擴容!如果超出閥值,就進行擴容處理,創建一個更大容量的 hash 表,然後把從老的 Hash 表中遷移到新的 Hash 表中,源碼如下:

將舊 hash 表中的元素複製到新的 hash 表中,源碼如下:

整個 put 過程,大致可以分如下幾個步驟:

  • 第一步是通過 key 計算出來的 hash 和 equals 來判斷元素是否存在,如果存在,直接覆蓋;反之,插入;
  • 第二步是將元素插入到 hash 表中,如果不同的元素都在一個 hash 數組下標下,就以鏈表的形式,採用頭插法存儲在 hash 節點下;
  • 最後就是判斷當前數組容量是否大於擴容閥值,如果大於,就進行擴容處理,然後將舊元素複製到新的數組中;

好了,這個過程基本上沒啥問題。

我們再來演示一下擴容中重新計算元素 hash 的過程!

3.2、單線程下擴容元素 hash 過程

假設在單線程環境下,我們初始化的時候,給定的數組容量是2,分別添加3個元素,內容如下:

  • key=3,value=A;
  • key=4,value=B;
  • key=5,value=C;

源碼如下:

添加完成之後,數組就會進行擴容處理,擴容後 hash 的容量爲原來的2倍,擴容操作流程如下:

在單線程環境下,一切看起來都很正常,擴容過程也相當順利。接下來我們看下併發情況下的擴容。

3.3、多線程擴容元素 hash 過程

假設我們有兩個線程,來分別添加3個元素。

線程二執行完添加任務之後,在準備將舊元素遷移到新元素的時候,也就是準備 rehash 時,突然被 CPU 掛起,此時阻塞在如下圖中的第57行,不再往下執行!而線程一繼續執行直到擴容完成。

2個線程此時的執行結果,內容如下:

接着線程二被喚醒,繼續回到第57行執行。

此時注意了,我們來詳細的分析一下這個過程!

第一次循環過程如下:

  • 第1步:此時 e 等於{key:3,value:A},next=e.next={key:5,value:C}
  • 第2步:通過 key 重新 hash 計算得到下標 i = 3
  • 第3步:newTable爲局部變量,內容都爲null,所以 e.next = newTable[i]=null;
  • 第4步:newTable[i]=e={key:3,value:A};
  • 第5步:e=next={key:5,value:C};

循環結果如下,e={key:5,value:C},滿足while()循環條件,接着繼續!

第二次循環過程如下:

  • 第1步:此時 e 等於{key:5,value:C},取最新的鏈表結構,next=e.next={key:3,value:A}
  • 第2步:通過 key 重新 hash 計算得到下標 i = 3
  • 第3步:在第一次循環中,newTable[i]已經插入值,所以 e.next = newTable[i]={key:3,value:A};
  • 第4步:newTable[i]=e={key:5,value:C};
  • 第5步:e=next={key:3,value:A};

循環結果如下,e={key:3,value:A},滿足while()循環條件,接着繼續!

第三次循環過程如下:

  • 第1步:此時 e 等於{key:3,value:A},取最新的鏈表結構,next=e.next=null
  • 第2步:通過 key 重新 hash 計算得到下標 i = 3
  • 第3步:在第二次循環中,newTable[i]已經插入值,所以 e.next = newTable[i]={key:5,value:C};
  • 第4步:newTable[i]=e={key:3,value:A};
  • 第5步:e=next=null;

循環結果如下,e=nullwhile()程序不在循環!

綜合線程1、線程2執行結果,最終 hashMap 的存儲結果,如下圖:

可以很清晰的看到,鏈表發生死循環了!

於是,當我們在遍歷 hashMap 鏈表內容的時候,就會出現上文中問題復現的場景,死循環式的輸出相同的內容,CPU 直接飆到200%了!

對於這種問題,當初有人上報到 SUN 公司,但是 SUN 不認爲這是一個問題,因爲 HashMap 本來就不支持併發操作!

所以,不建議在多線程環境下使用 HashMap,那如果要在多線程環境下使用 map 操作類,該怎麼辦呢?

四、解決辦法

辦法肯定是有的,如果大家想在多線程場景下使用 HashMap,有兩種解決辦法:

  • 第一種,推薦使用併發包中的 ConcurrentHashMap 類,一種使用分段鎖的 hashMap 類,在之後的文章中,咱們也會介紹到它。
  • 另一種,是使用Collections.synchronizedMap(Mao<K,V> map)工具方法,將 HashMap 變成一個線程安全的 map,其實就是對 map 中的方法進行加鎖處理,保證多線程下操作安全!

五、參考

1、JDK1.7&JDK1.8 源碼

2、coolshell -陳皓 - JAVA HASHMAP的死循環

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章