[轉]不正當使用HashMap致使cpu 100%的問題追究

之前項目中遇到相似業務，但使用的是CurrentHashMap，看到這篇文章，轉載記錄，警示本身。

如下內容轉自：

轉載自併發編程網 – ifeve.com（http://ifeve.com/hashmap-infinite-loop/）

-------------------------------------分割線-----------------------------------------------------------------

因最近hashmap誤用引發的死循環又發生了一些案例，左耳朵浩子寫了一篇blog 疫苗：Java HashMap的死循環，看了一下，你們的分析一模一樣。這篇blog也是好幾年前寫的了，以前在平臺技術部的博客上貼過，隨着組織結構的調整，那個博客可能再也不維護，把這篇文章在這兒也保存一下。

李鵬同窗在blog裏寫了篇關於HashMap死鎖模擬的文章: http://blog.csdn.net/madding/archive/2010/08/25/5838477.aspx 作個糾正,那個不是死鎖問題,而是死循環。

這個問題,咱們之前討論過。 校長以前的博客和淘寶的畢玄的《分佈式Java應用:基礎與實踐》一書中都提到過 velocity致使cpu 100% 的bug,原由是HashMap的使用不當所致。

在以前的郵件列表裏,校長提出過這個問題,當時我沒仔細看,不清楚這個問題到底是對 HashMap的誤用,仍是HashMap的潛在問題, 當時感受不太多是HashMap自身的問題,不然問題大了。應該是屬於在併發的場景下錯誤的 使用了HashMap。昨天看了李鵬的blog後,以爲這個事情仍是應該搞清楚一下;雖然我推測是鏈表造成閉環,但 沒有去證實過。從網上找了一下: http://blog.csdn.net/autoinspired/archive/2008/07/16/2662290.aspx 裏面也有提到:

產生這個死循環的根源在於對一個未保護的共享變量 — 一個」HashMap」數據結構的操做。當在 全部操做的方法上加了」synchronized」後,一切恢復了正常。檢查」HashMap」(Java SE 5.0)的源 碼,咱們發現有潛在的破壞其內部結構最終形成死循環的可能。在下面的代碼中,若是咱們使得 HashMap中的entries進入循環,那 麼」e.next()」永遠都不會爲null。

僅get()方法會這樣,put()以及其餘對外暴露的方法都會有這個風險,這算jvm的bug嗎?應該說不是的,這個現象很早之前就報告出來了(詳細見: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6423457)。Sun的工程師並不認爲這 是bug,而是建議在這樣的場景下應用」ConcurrentHashMap」,在構建可擴展的系統時應將這點 歸入規範中。

這篇翻譯提到了對HashMap的誤用,但它沒有點破HashMap內部結構在什麼樣誤用狀況下怎麼被 破壞的;我想要一個有力的場景來弄清楚。再從李鵬的blog來看,用了2個線程來put就模擬出來了,最後堆棧是在 transfer 方法上(該方法是數據擴容時將數據從舊容器轉移到新容器)。 仔細分析了一下里面的代碼,基本得出了緣由,證實了我以前的推測。

假設擴容時的一個場景以下(右邊的容器是一個長度 2 倍於當前容器的數組) 單線程狀況。

咱們分析數據轉移的過程,主要是鏈表的轉移。

執行過一次後的狀態:

最終的結果:

兩個線程併發狀況下,擴容時可能會建立出 2 個新數組容器

順利的話,最終轉移完多是這樣的結果

但併發狀況下,出現死循環的可能場景是什麼呢? 還要詳細的分析一下代碼,下面的代碼中重點在 do/while 循環結構中(完成鏈 表的轉移)。

// 擴容操做,從一個數組轉移到另外一個數組
void transfer(Entry[] newTable) { 
    Entry[] src = table;
    int newCapacity = newTable.length; 
    for (int j = 0; j < src.length; j++) {
        Entry<K,V> e = src[j]; 
        if (e != null) {
            src[j] = null; 
            do {
                Entry<K,V> next = e.next; //假設第一個線程執行到這裏 
                int i = indexFor(e.hash, newCapacity);
                e.next = newTable[i];
                newTable[i] = e;
                e = next;
            } while (e != null); // 可能致使死循環
        }
    }
}

2 個線程併發狀況下, 當線程 1 執行到上面第 9 行時,而線程 2 已經完成了一 輪 do/while 操做,那麼它的狀態以下圖:
(上面的數組時線程 1 的,已經完成了鏈表數據的轉移;下面的是線程 2 的,它 即將開始進行對鏈表數據的轉移,此時它記錄 E1 和 E2 的首位已經被線程 1 翻 轉了)

後續的步驟以下:

1) 插入 E1 節點,E1 節點的 next 指向新容器索引位置上的值(null 或 entry)

2) 插入 E2 節點,E2 的 next 指向當前索引位置上的引用值 E1

3)由於 next 不爲 null,鏈表繼續移動,此時 2 節點之間造成了閉環。形成了死循環。

上面只是一種狀況,形成單線程死循環,雙核 cpu 的話佔用率是 50%,還有致使 100%的狀況,應該也都是鏈表的閉環所致。

最終,這並非 HashMap 的問題,是使用場景的不當,在併發狀況下選擇非線程 安全的容器是沒有保障的。

相關閱讀：深刻剖析ConcurrentHashMap(1)，深刻剖析ConcurrentHashMap(2)