HashMap多執行緒不安全
事故分析
最近一次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.doTransformTweetT 5(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進行put操作,
問題就這樣引起了,HashMap是非執行緒安全的,多個執行緒put的時候造成了某個key值Entry key List的死迴圈,問題就這麼產生了。
當另外一個執行緒get 這個Entry List 死迴圈的key的時候,這個get也會一直執行。最後結果是越來越多的執行緒死迴圈,最後導致伺服器dang掉。解決辦法也很簡單,就不多說了
我們一般認為HashMap重複插入某個值的時候,會覆蓋之前的值,這個沒錯。但是對於多執行緒訪問的時候,由於其內部實現機制,就可能出現安全問題了。正如<<併發程式設計實踐>>所說,當某個類沒有什麼是執行緒安全的時候,就認為它是非執行緒安全的。
對HaspMap死迴圈原因分析
有人已經做出了分析,我就不在大費周章了。連結如下:
問題:
分析:http://www.udpwork.com/item/2321.html
http://www.shaoqun.com/a/213108.aspx
相關推薦
HashMap多執行緒不安全
事故分析 最近一次web工程上線,上線大概半個小時,出現了報警,16核的伺服器的cpu使用了1123%,程式出異常了。 Cpu利用率過高一般是因為出現了出現了死迴圈,導致部分執行緒一直執行。佔用cpu時間。使用jstack工具dump出問題的那臺伺服器的棧資
java中為什麼Hashtable是執行緒安全的,而HashMap是執行緒不安全的?還有ArrayList為什麼是執行緒不安全的,Vector是執行緒安全的??
文章目錄 一、HashMap解析 二、Hashtable解析 三、Collections.synchronizedMap()解析 四、ConcurrentHashMap 六、ArrayList為什麼是執行緒不安全的,Vector是執行緒安全的?
java-雙重檢查鎖為什麼多執行緒不安全
如下程式碼所示: public class doubleCheck{ private static Instance instance; public static Instance getInstance(){ if(instance==null){ //1
高併發下的HashMap(執行緒不安全)
高併發下的HashMap 這些討論是在1.8之前的java下作的分析,1.8的HashMap做了很大的變化,可以保證高併發下的安全性(多執行緒)。 HashMap的容量是有限的。當經過多次元素插入,使得HashMap達到一定飽和度時,Key對映位置發生衝突的
hashmap為什麼執行緒不安全,出現死迴圈
2018年11月18日 09:07:49 坑鏗吭 閱讀數:12 個人分類: java
HashMap為什麼執行緒不安全(hash碰撞與擴容導致)
一直以來都知道HashMap是執行緒不安全的,但是到底為什麼執行緒不安全,在多執行緒操作情況下什麼時候執行緒不安全? 讓我們先來了解一下HashMap的底層儲存結構,HashMap底層是一個Entry陣列,一旦發生Hash衝突的的時候,HashMap採用拉鍊法解決碰撞衝突,Entry內部的變數: fi
C++STL容器部分操作多執行緒不安全
最近專案中發現一個c++stl容器多執行緒查詢可能出現CPU佔用率100%的問題。 問題是這樣的,執行緒A和執行緒B共享一個stl::map。其中執行緒A對map有查詢的操作,執行緒B對map有
hashMap的執行緒不安全,從原始碼談起
HashMap的原理以及如何實現,之前在JDK7與JDK8中HashMap的實現中已經說明了。 那麼,為什麼說HashMap是執行緒不安全的呢?它在多執行緒環境下,會發生什麼情況呢? resize死迴圈 我們都知道HashMap初始容量大小為16,一般來說,當有資料要插入時,
證明HashMap是執行緒不安全的
在平時開發中,我們經常採用HashMap來作為本地快取的一種實現方式,將一些如系統變數等資料量比較少的引數儲存在HashMap中,並將其作為單例類的一個屬性。在系統執行中,使用到這些快取資料,都可以直接從該單例中獲取該屬性集合。但是,最近發現,HashMap並不是執行緒安
淺談Java8的HashMap為什麼執行緒不安全
PS:本文使用的Java原始碼是JDK1.8。 事情起因很簡單,起源於類似you can,you up的玩笑。我這人喜歡較真,尤其是遇見我會的問題的時候。 我們先上一組程式碼。 public static void main(String[] ar
為什麼HashMap是執行緒不安全類?
本文轉載自:http://blog.csdn.net/mydreamongo/article/details/8960667 一直以來只是知道HashMap是執行緒不安全的,但是到底HashMap為什麼執行緒不安全,多執行緒併發的時候在什麼情況下可能出現問題? Has
java 中如何避免多執行緒不安全
1.建立不可變物件 2. 執行緒封閉:把一個可變物件封裝到一個執行緒內部,或者使用ThreadLocal 3.使用volatile變數 volatile變數記憶體語義 1. 當對一個volatile變數進行寫操作的時候,JMM會把該執行緒對應的
HashMap多執行緒不建議使用
package com.jay.test.map; import java.util.HashMap; import java.util.Map; import java.util.concurrent.ConcurrentHashMap; public class M
HashMap執行緒不安全的表現 -- Java 8
HashMap執行緒不安全的表現 -- Java 8 先來看看HashMap.put方法的原始碼 public V put(K key, V value) { return putVal(hash(key), key, value, false, true); }
HashMap為什麼是執行緒不安全的?
一直以來只是知道HashMap是執行緒不安全的,但是到底HashMap為什麼執行緒不安全,多執行緒併發的時候在什麼情況下可能出現問題? HashMap底層是一個Entry陣列,當發生hash衝突的時候,hashmap是採用連結串列的方式來解決的,在對應的陣列位置存放連結串列
Java併發程式設計 之 HashMap執行緒不安全
我想在平時的多執行緒程式設計中,容器的使用是很普遍的,但是你有沒有考慮過有些容器是不安全的,如Haspmap、ArrayList。這裡講解一下Hashmap不安去體現在哪裡。 插入時不安全: 如果有兩個執行緒A和B,都進行插入資料,剛好經過雜湊計算後得到的雜湊碼是一樣的,即插入的
從Java1.8原始碼角度剖析執行緒不安全的HashMap
文章目錄 HashMap的底層核心資料結構是什麼? HashMap包含哪些資料結構? 雜湊槽(slot)的位置是如果確定的?如何避免雜湊衝突? resize()是如何實現的? 為什麼執行緒不安全? 什麼時候會樹化?
談談HashMap執行緒不安全的體現
我們先回顧一下HashMap。HashMap是一個數組連結串列,當一個key/Value對被加入時,首先會通過Hash演算法定位出這個鍵值對要被放入的桶,然後就把它插到相應桶中。如果這個桶中已經有元素了,那麼發生了碰撞,這樣會在這個桶中形成一個連結串列。一般來說,當有資料要插
解決多執行緒單例模式的執行緒不安全問題
DCL雙檢查鎖機制 public class MyConfig { private volatile static MyConfig myConfig = null;//volatile
Qt多執行緒程式設計總結(一)(所有GUI物件都是執行緒不安全的)
Qt對執行緒提供了支援,基本形式有獨立於平臺的執行緒類、執行緒安全方式的事件傳遞和一個全域性Qt庫互斥量允許你可以從不同的執行緒呼叫Qt方法。 這個文件是提供給那些對多執行緒程式設計有豐富的知識和經驗的聽眾的。推薦閱讀: 警告:所有的GUI類(比如,QWidget和它的子類),作業系統核心類(比如,QPr