1樓：看雲
1.8雖然沒有了死鏈的問題，但還是存在size()問題,++size不是原子操作，想想自己可以寫乙個多執行緒對乙個靜態變數做自增操作看出來的結果跟想的是不是一樣即可
2樓：Learner
文件裡都說不是執行緒安全的，然後非要在多執行緒環境下用，出了問題各種分析
告訴你前面有地雷，走過去炸死了，不斷分析為什麼會被炸死
3樓：WTIFS
hashMap進行put操作時的流程是：先計算hashCode找到桶，然後遍歷桶內的鍊錶找到插入位置插入。即先查後寫。但凡先查後寫的，在併發環境下都會有併發查詢問題
舉個例子，比如有兩個待寫入的鍵值對，剛好落到同乙個桶裡，假設這個桶是0號桶，這個桶裡有乙個元素c。
單執行緒環境下，我們先查a準備寫入的位置，查到是0號桶的c後面的位置，之後寫入a。然後查b準備寫入的位置，查到是0號桶的a後面的位置，之後寫入b。兩個鍵值對都能正常被寫入。
多執行緒環境下，a的查詢可能和b是同步進行的。執行緒t1的查詢裡，a的寫入位置是c後面，c.next=a；執行緒t2的查詢裡，b的寫入位置也是c後面（因為此刻a尚未插入）, c.
next=b。最終先插入c後面的會被後寫的覆蓋，只有後寫的那個會被實際成功寫入。
ConcurrentHashMap是怎麼解決這樣的併發問題的呢？其實很簡單，就是在寫入時對0號桶加鎖，加鎖期間別的執行緒需要等待鎖釋放後才能寫入。比如執行緒t1寫入a時加了鎖，那麼執行緒t2必須等待a寫完才能寫入b，這時b的寫入位置是a後面，a.
next=b，a和b都能正常被寫入。（這是jdk1.7的做法，1.
8改為CAS了）
4樓：李曉東
hashmap不適合併發的根本是他的put get沒有做同步處理，死迴圈只是併發時會出現的一種較嚴重的問題，據我所知1.8的hashmap引入了紅黑樹，但是預設hash鏈長度大於8時才會轉成紅黑樹，關於併發支援並沒有實質的改進吧
為什麼說Blackpink中jennie的《solo》音源注水？
女團博愛粉 笑暈了，一口乙個女solo打不過男團，說注水又沒證據，不阿 我不喜歡這姐但是solo音源就是好啊說注水就拿出證據別虛空對線和 magic 真的服了某個匿名的了。jennie要是一直solo的話隊友粉不得罵死？墨粉圈本身蠻亂的。hylt時期就是因為粉圈太亂導致我粉轉路現在有轉粉跡象算路人粉...
為什麼說索尼最新發布的135mm F1 8 GM鏡頭，國行定價13000元不貴？
澳洲威廉William 座標墨爾本，看了很久知乎，也上來貢獻一些。8月入手sony GM135 1.8,封城不能出去拍照，上週天氣好門口小公園拍寶寶，後期加了調色。這顆頭的素質真棒。希望解封後繼續拍。 夢羽靈泉 問題應該改成 為什麼說索尼最新發布的135mm F1.8 GM鏡頭，國行定價13000元...
python中為什麼說元組不可改變？
狼大人 如果問的是 為什麼有了 List 還要不可修改的 Tuple 的話，有一些地方是必須使用不能修改的型別的，比如 Dict 的 key，或者 set 元素。本身不管是 hash 還是 tree，你直接做了 inplace 修改的話，整個表結構都是被破壞的。這個時候就不能用 List，而必須用 ...