從前我們的java代碼因為一些原因使用了hashmap這個東西，但是當時的程式是單線程的，一切都沒有問題。後來，我們的程式性能有問題，是以需要變成多線程的，于是，變成多線程後到了線上，發現程式經常占了100%的cpu，檢視堆棧，你會發現程式都hang在了hashmap.get()這個方法上了，重新開機程式後問題消失。但是過段時間又會來。而且，這個問題在測試環境裡可能很難重制。
我們簡單的看一下我們自己的代碼，我們就知道hashmap被多個線程操作。而java的文檔說hashmap是非線程安全的，應該用concurrenthashmap。但是在這裡我們可以來研究一下原因。簡單代碼如下：
就是啟了10個線程，不斷的往一個非線程安全的hashmap中put内容/get内容，put的内容很簡單，key和value都是從0自增的整數（這個put的内容做的并不好，以緻于後來幹擾了我分析問題的思路）。對hashmap做并發寫操作，我原以為隻不過會産生髒資料的情況，但反複運作這個程式，會出現線程t1、t2被hang住的情況，多數情況下是一個線程被hang住另一個成功結束，偶爾會10個線程都被hang住。
産生這個死循環的根源在于對一個未保護的共享變量 — 一個”hashmap”資料結構的操作。當在所有操作的方法上加了”synchronized”後，一切恢複了正常。這算jvm的bug嗎？應該說不是的，這個現象很早以前就報告出來了。sun的工程師并不認為這是bug，而是建議在這樣的場景下應采用”concurrenthashmap”，
cpu使用率過高一般是因為出現了出現了死循環，導緻部分線程一直運作，占用cpu時間。問題原因就是hashmap是非線程安全的，多個線程put的時候造成了某個key值entry key list的死循環，問題就這麼産生了。
當另外一個線程get 這個entry list 死循環的key的時候，這個get也會一直執行。最後結果是越來越多的線程死循環，最後導緻伺服器dang掉。我們一般認為hashmap重複插入某個值的時候，會覆寫之前的值，這個沒錯。但是對于多線程通路的時候，由于其内部實作機制(在多線程環境且未作同步的情況下，對同一個hashmap做put操作可能導緻兩個或以上線程同時做rehash動作，就可能導緻循環鍵表出現，一旦出現線程将無法終止，持續占用cpu，導緻cpu使用率居高不下)，就可能出現安全問題了。
使用jstack工具dump出問題的那台伺服器的棧資訊。死循環的話，首先查找runnable的線程，找到問題代碼如下：
java.lang.thread.state:runnable at java.util.hashmap.get(hashmap.java:303) at com.sohu.twap.service.logic.transformtweeter.dotransformtweett5(transformtweeter.java:183) 共出現了23次。 at java.util.hashmap.put(hashmap.java:374) at com.sohu.twap.service.logic.transformtweeter.transformt5(transformtweeter.java:816) 共出現了3次。
注意：不合理使用hashmap導緻出現的是死循環而不是死鎖。
主要問題出在addentry方法的new entry (hash, key, value, e)，如果兩個線程都同時取得了e,則他們下一個元素都是e，然後指派給table元素的時候有一個成功有一個丢失。
在transfer方法中代碼如下：
在這個方法裡，将舊數組指派給src，周遊src，當src的元素非null時，就将src中的該元素置null，即将舊數組中的元素置null了，也就是這一句：
此時若有get方法通路這個key，它取得的還是舊數組，當然就取不到其對應的value了。
總結：hashmap未同步時在并發程式中會産生許多微妙的問題，難以從表層找到原因。是以使用hashmap出現了違反直覺的現象，那麼可能就是并發導緻的了。
我需要簡單地說一下hashmap這個經典的資料結構。
hashmap通常會用一個指針數組（假設為table[]）來做分散所有的key，當一個key被加入時，會通過hash算法通過key算出這個數組的下标i，然後就把這個 插到table[i]中，如果有兩個不同的key被算在了同一個i，那麼就叫沖突，又叫碰撞，這樣會在table[i]上形成一個連結清單。
我們知道，如果table[]的尺寸很小，比如隻有2個，如果要放進10個keys的話，那麼碰撞非常頻繁，于是一個o(1)的查找算法，就變成了連結清單周遊，性能變成了o(n)，這是hash表的缺陷。
是以，hash表的尺寸和容量非常的重要。一般來說，hash表這個容器當有資料要插入時，都會檢查容量有沒有超過設定的thredhold，如果超過，需要增大hash表的尺寸，但是這樣一來，整個hash表裡的元素都需要被重算一遍。這叫rehash，這個成本相當的大。
下面，我們來看一下java的hashmap的源代碼。put一個key,value對到hash表中：
檢查容量是否超标：
建立一個更大尺寸的hash表，然後把資料從老的hash表中遷移到新的hash表中。
遷移的源代碼，注意高亮處：
好了，這個代碼算是比較正常的。而且沒有什麼問題。
畫了個圖做了個示範。
我假設了我們的hash算法就是簡單的用key mod 一下表的大小（也就是數組的長度）。
接下來的三個步驟是hash表 resize成4，然後所有的 重新rehash的過程。
（1）假設我們有兩個線程。我用紅色和淺藍色标注了一下。我們再回頭看一下我們的 transfer代碼中的這個細節：
而我們的線程二執行完成了。于是我們有下面的這個樣子。
注意：因為thread1的 e 指向了key(3)，而next指向了key(7)，其線上程二rehash後，指向了線程二重組後的連結清單。我們可以看到連結清單的順序被反轉後。
（2）線程一被排程回來執行。
先是執行 newtalbe[i] = e。
然後是e = next，導緻了e指向了key(7)。
而下一次循環的next = e.next導緻了next指向了key(3)。
（3）一切安好。
線程一接着工作。把key(7)摘下來，放到newtable[i]的第一個，然後把e和next往下移。
（4）環形連結出現。
e.next = newtable[i] 導緻 key(3).next 指向了 key(7)。注意：此時的key(7).next 已經指向了key(3)， 環形連結清單就這樣出現了。
于是，當我們的線程一調用到，hashtable.get(11)時，悲劇就出現了——infinite loop。
hashtable 是同步的，但由疊代器傳回的 iterator 和由所有 hashtable 的“collection 視圖方法”傳回的 collection 的 listiterator 方法都是快速失敗的：在建立 iterator 之後，如果從結構上對 hashtable 進行修改，除非通過 iterator 自身的移除或添加方法，否則在任何時間以任何方式對其進行修改，iterator 都将抛出 concurrentmodificationexception。是以，面對并發的修改，iterator 很快就會完全失敗，而不冒在将來某個不确定的時間發生任意不确定行為的風險。由
hashtable 的鍵和值方法傳回的 enumeration 不是快速失敗的。
注意，疊代器的快速失敗行為無法得到保證，因為一般來說，不可能對是否出現不同步并發修改做出任何硬性保證。快速失敗疊代器會盡最大努力抛出 concurrentmodificationexception。是以，為提高這類疊代器的正确性而編寫一個依賴于此異常的程式是錯誤做法：疊代器的快速失敗行為應該僅用于檢測程式錯誤。
傳回由指定映射支援的同步（線程安全的）映射。為了保證按順序通路，必須通過傳回的映射完成對底層映射的所有通路。在傳回的映射或其任意 collection 視圖上進行疊代時，強制使用者手工在傳回的映射上進行同步：
不遵從此建議将導緻無法确定的行為。如果指定映射是可序列化的，則傳回的映射也将是可序列化的。
支援檢索的完全并發和更新的所期望可調整并發的哈希表。此類遵守與 hashtable 相同的功能規範，并且包括對應于 hashtable 的每個方法的方法版本。不過，盡管所有操作都是線程安全的，但檢索操作不必鎖定，并且不支援以某種防止所有通路的方式鎖定整個表。此類可以通過程式完全與 hashtable 進行互操作，這取決于其線程安全，而與其同步細節無關。
檢索操作（包括 get）通常不會受阻塞，是以，可能與更新操作交疊（包括 put 和 remove）。檢索會影響最近完成的更新操作的結果。對于一些聚合操作，比如 putall 和 clear，并發檢索可能隻影響某些條目的插入和移除。類似地，在建立疊代器/枚舉時或自此之後，iterators 和 enumerations 傳回在某一時間點上影響哈希表狀态的元素。它們不會抛出 concurrentmodificationexception。不過，疊代器被設計成每次僅由一個線程使用。