事故分析

最近一次web工程上線，上線大概半個小時，出現了報警，16核的伺服器的cpu使用了1123%，程式出異常了。

Cpu利用率過高一般是因為出現了出現了死迴圈，導致部分執行緒一直執行。佔用cpu時間。使用jstack工具dump出問題的那臺伺服器的棧資訊。死迴圈的話，首先查詢RUNNABLE的執行緒，找到問題程式碼如下：

java.lang.Thread.State:RUNNABLE

         at java.util.HashMap.get(HashMap.java:303)

atcom.sohu.twap.service.logic.TransformTweeter.doTransformTweetT5(TransformTweeter.java:183)

共出現了23次。

java.lang.Thread.State:RUNNABLE

         at java.util.HashMap.put(HashMap.java:374)

         atcom.sohu.twap.service.logic.TransformTweeter.transformT5(TransformTweeter.java:816)

共出現了3次。

問題原因已經顯而易見。先說說這個Hashmap的使用的方法，在伺服器啟動之後，第一個訪問這個map的時候進行初始化，以後不再變化。hashmap作為TransformTweeter的static成員，也就是類成員。

關鍵程式碼：

privatestatic Map<String,String>expressionMap =newHashMap<String, String>();

先來分析初始化方法：

上面的棧資訊顯示有三個執行緒在對HashMap進行put操作，這顯然是違背了作者的本意的。看798行，expressionMap.size==0 這個判讀，在多個執行緒併發操作的的時候，可能存在（這裡用一定也不過分）多個執行緒進入這段初始化程式碼。

問題就這樣引起了，HashMap是非執行緒安全的，多個執行緒put的時候造成了某個key值Entry key List的死迴圈，問題就這麼產生了。

當另外一個執行緒get 這個Entry List 死迴圈的key的時候，這個get也會一直執行。最後結果是越來越多的執行緒死迴圈，最後導致伺服器dang掉。解決辦法也很簡單，就不多說了

我們一般認為HashMap重複插入某個值的時候，會覆蓋之前的值，這個沒錯。但是對於多執行緒訪問的時候，由於其內部實現機制，就可能出現安全問題了。正如<<併發程式設計實踐>>所說，當某個類沒有什麼是執行緒安全的時候，就認為它是非執行緒安全的。

對HaspMap死迴圈原因分析

有人已經做出了分析，我就不在大費周章了。連結如下：