ConcurrentHashMap和HashMap的實現原理是差不多的，但是因為ConcurrentHashMap需要支持并發操作，所以在實現上要比hashmap稍微復雜一些。

在JDK1.7的實現上，ConrruentHashMap由一個個Segment組成，簡單來說，ConcurrentHashMap是一個Segment數組，它通過繼承ReentrantLock來進行加鎖，通過每次鎖住一個segment來保證每個segment內的操作的線程安全性從而實現全局線程安全。整個結構圖如下

當每個操作分布在不同的segment上的時候，默認情況下，理論上可以同時支持16個線程的并發寫入

相比于1.7版本，它做了兩個改進

1. 取消了segment分段設計，直接使用Node數組來保存數據，并且采用Node數組元素作為鎖來實現每一行數據進行加鎖來進一步減少并發沖突的概率

2. 將原本數組+單向鏈表的數據結構變更為了數組+單向鏈表+紅黑樹的結構。為什么要引入紅黑樹呢？在正常情況下，key?hash之后如果能夠很均勻的分散在數組中，那么table數組中的每個隊列的長度主要為0或者1.但是實際情況下，還是會存在一些隊列長度過長的
情況。如果還采用單向列表方式，那么查詢某個節點的時間復雜度就變為O(n);?因此對于隊列長度超過8的列表，JDK1.8采用了紅黑樹的結構，那么查詢的時間復雜度就會降低到O(logN),可以提升查找的性能；

這個結構和JDK1.8版本中的Hashmap的實現結構基本一致，但是為了保證線程安全性，ConcurrentHashMap的實現會稍微復雜一下。接下來我們從源碼層面來了解一下它的原理.?

我們基于put和get方法來分析它的實現即可

put方法第一階段

public V put(K key, V value) { return putVal(key, value, false); }

假如在上面這段代碼中存在兩個線程，在不加鎖的情況下：線程A成功執行casTabAt操作后，隨后的線程B可以通過tabAt方法立刻看到table[i]的改變。原因如下：線程A的casTabAt操作，具有volatile讀寫相同的內存語義，根據volatile的happens-before規則：線程A的casTabAt操作，一定對線程B的tabAt操作可見

?

總結

以上是生活随笔為你收集整理的ConcurrentHashMap的源码分析-JDK1.7和Jdk1.8版本的变化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。