前言
之前我們講了線程，鎖以及隊列同步器等等一些併發相關底層的東西，當然Java開發者在開發中很少直接去使用之前所講的，因爲Java爲了簡化開發，爲我們提供了一整套併發容器和框架，但是這些容器和框架都是建立在之前所講的基礎之上的，今天就讓我們來看第一個併發容器：ConcurrentHashMap，我們主要從原理和使用兩個方面介紹，讓我們揚帆起航，開始今天的併發之旅吧。
景點一：爲什麼要使用ConcurrentHashMap
ConcurrentHashMap是一個線程安全並且高效的HashMap，基於下面兩點我們還是在併發場景中優先考慮ConcurrentHashMap。
-
線程不安全的HashMap：在多線程環境下，使用HashMap進行操作會引起死循環，導致CPU100%甚至服務器之間崩潰，讀者可以參考下面代碼自己試一下，（親測使用Hash服務器直接卡死，不信U CAN TRY）：多線程會導致HashMap的Entry鏈表形成環形數據結構，一旦形成環，那麼Entry的next節點永遠不爲空，Hash就會陷入死循環獲取Entry的場景
public class ConcurrentMapDemo {
public static void main(String[] args) throws InterruptedException {
// final HashMap<String, String> map = new HashMap<String, String>();
final ConcurrentHashMap map = new ConcurrentHashMap<>();
Thread t1 = new Thread(new Runnable() {
@Override
public void run() {
for (int i = 0; i < 1000; i++) {
new Thread(new Runnable() {
@Override
public void run() {
for (int i = 0; i < 1000; i++) {
map.put(UUID.randomUUID().toString(), "");
}
}
}, "t2").start();
}
}
}, "t1");
t1.start();
}
}
-
效率低下的HashTable：HashTable是使用synchronized來保證線程安全，但是在多線程併發環境下線程競爭激烈，HashTable的效率非常低，也正是因爲synchronized導致每次只能有一個線程訪問同步塊，其他線程處於阻塞或者輪詢狀態，根本無法對同步塊進行任何操作，所以線程競爭越激烈（線程數量越多），效率越低，這明顯不滿足我們使用多線程的初衷；
-
ConcurrentHashMap鎖分段技術：ConcurrentHashMap內部使用段（segment）來表示這些不同的部分，每個段其實就是一個小的HashTable，他們有自己各自的鎖，只要多個修改操作發生在不同的段上，他們之間就可以併發的進行；
景點二：ConcurrentHashMap的結構
通過上面的結構圖，我們來分析下：ConcurrentHashMap是由Segment數組結構和HashEntry數組結構組成，Segment是一種可重入鎖，在ConcurrentHashMap中充當鎖的角色，HashEntry是用來存儲鍵值對數據。這三者的關係如下圖：
景點三：ConcurrentHashMap的底層實現
ConcurrentHashMap把一個整體分成16個段（segment），也就是說最高支持16個線程的併發修改操作。這也是在多線程場景下減小鎖粒度從而降低競爭的一種方案。並且代碼中大多共享變量使用volatile關鍵字，目的是第一時間獲取修改的內容，性能非常好。
ConcurrentHashMap的底層主要包括初始化Segment數組、SegmentShift、SegmentMask和每個Segment裏面的HashEntry數組以及Segment的定位，下面我們將來一一分析：
初始化Segment數組：
if (concurrencyLevel > MAX_SEGMENTS)
concurrencyLevel = MAX_SEGMENTS;
// segments數組的長度ssize通過concurrencyLevel計算得出。
//爲了能通過按位與的哈希算法來定位segments數組的索引，
//必須保證segments數組的長度是2的N次方
// 所以必須計算出一個是大於或等於concurrencyLevel的最小的2的N次方值來作爲segments數組的長度
int sshift = 0;
int ssize = 1;
while (ssize < concurrencyLevel) {
++sshift;
ssize <<= 1;
}
this.segmentShift = 32 - sshift;
this.segmentMask = ssize - 1;
初始化SegmentShift和SegmentMask：這兩個全局變量在定位segment時的哈希散列中使用，sshift等於ssize從1向左移位的次數，在默認情況下concurrencyLevel等於16，1需要向左移位移動4次，所以sshift等於4。segmentShift用於定位參與hash運算的位數，segmentShift等於32減sshift，所以等於28，這裏之所以用32是因爲ConcurrentHashMap裏的hash()方法輸出的最大數是32位的。
segmentMask是哈希運算的掩碼，等於ssize減1，即15，掩碼的二進制各個位的值都是1。因爲ssize的最大長度是65536，所以segmentShift最大值是16，segmentMask最大值是65535，對應的二進制是16位，每個位都是1；
初始化每個Segment裏面的HashEntry：
// initialCapacity是ConcurrentHashMap的初始化容量
// loadFactor是每個Segment的負載因子
// cap爲Segment裏面HashEntry數組的長度，它等於initialCapacity/ssize的倍數c，如果c>1則就會取大於等於c的2的N次方值
// 所以cap如果不是1就是2的N次方。
// Segment的容量=(int)cap*loadFactor,默認情況下loadFactor=0.75，initialCapacity=16
if (initialCapacity > MAXIMUM_CAPACITY)
initialCapacity = MAXIMUM_CAPACITY;
int c = initialCapacity / ssize;
if (c * ssize < initialCapacity)
++c;
int cap = MIN_SEGMENT_TABLE_CAPACITY;
while (cap < c)
cap <<= 1;
// create segments and segments[0]
Segment<K,V> s0 = new Segment<K,V>(loadFactor, (int)(cap * loadFactor),(HashEntry<K,V>[])new HashEntry[cap]);
Segment<K,V>[] ss = (Segment<K,V>[])new Segment[ssize];
定位Segment：ConcurrentHashMap使用分段鎖Segment來保護每段數據，那麼在插入和獲取元素的時候，必須先通過哈希算法定位到Segment，ConcurrentHashMap會對元素的HashCode在進行一次hash散列，進行2次哈希的目的是減少散列衝突，使元素能夠均勻地分佈在不同的Segment上，提高容器的存取效率。
如果哈希散列最壞的情況是所有元素元素全部散落在一個Segment中，那麼分段鎖的意義就沒有了，而且存取效率也極差，所以爲了儘量減少散列衝突ConcurrentHashMap是通過2次哈希來做的，我們可以看具體源碼如下：
// segmentShift默認情況下=28
// segmentMask默認情況下=15
private Segment<K,V> segmentForHash(int h) {
// hash值右移28位（讓高4位參與到散列中） 再和segmentShift做與運算
long u = (((h >>> segmentShift) & segmentMask) << SSHIFT) + SBASE;
return (Segment<K,V>) UNSAFE.getObjectVolatile(segments, u);
}
景點四：ConcurrentHashMap的操作
ConcurrentHashMap的的方法有很多如下，我們主要講三種：get、put和size
put操作：
調用特別簡單跟使用HashMap沒有任何區別，如下：
ConcurrentHashMap concurrentHashMap = new ConcurrentHashMap<>();
concurrentHashMap.put("Justin","Justin的後端書架");
但是，由於ConcurrentHashMap是線程安全的所以put方法需要對共享變量進行寫入操作，所以爲了線程安全，必須加鎖，我們看下put的底層實現：
/**
* put方法首先定位到Segment，然後在Segment裏面進行插入操作
* 插入操作需要進行2步：
* 第一步：先判斷是否需要對Segment裏的HashEntry進行擴容，判斷HashEntry是否
* 是否超過容量threshold，如果超過閾值則進行擴容，Segment的擴容比
* Hashmap的擴容更合理，Hash是在插入元素之後再判斷是否需要進行擴容，
* 如果插入元素之後，滿足擴容條件，但是後續沒有元素新增，那就會做了一次無效的擴容
* 拓展：如何擴容？擴容的時候首先會創建一個兩倍於原容量的數組，然後將原數組裏的元素進行再hash後插入到新的數組裏。
* 爲了高效ConcurrentHashMap不會對整個容器進行擴容，而只對某個segment進行擴容
* 第二步是定位到添加元素的位置，然後將它放入HashEntry數組裏面
*/
public V put(K key, V value) {
Segment<K,V> s;
if (value == null)
throw new NullPointerException();
int hash = hash(key);
int j = (hash >>> segmentShift) & segmentMask;
if ((s = (Segment<K,V>)UNSAFE.getObject // nonvolatile; recheck
(segments, (j << SSHIFT) + SBASE)) == null) // in ensureSegment
s = ensureSegment(j);
return s.put(key, hash, value, false);
}
get操作：
使用很簡單：
ConcurrentHashMap concurrentHashMap = new ConcurrentHashMap<>();
concurrentHashMap.put("Justin","Justin的後端書架");
System.out.println(concurrentHashMap.get("Justin"));
我們再看下源碼實現：
/**
* 三步走：第一步，先對key經過一次再散列
* 第二步：使用這個散列值通過散列運算定位到Segment
* 第三步：再通過散列算法定位到元素
*/
public V get(Object key) {
Segment<K,V> s;
HashEntry<K,V>[] tab;
int h = hash(key);
long u = (((h >>> segmentShift) & segmentMask) << SSHIFT) + SBASE;
if ((s = (Segment<K,V>)UNSAFE.getObjectVolatile(segments, u)) != null &&
(tab = s.table) != null) {
for (HashEntry<K,V> e = (HashEntry<K,V>) UNSAFE.getObjectVolatile
(tab, ((long)(((tab.length - 1) & h)) << TSHIFT) + TBASE);
e != null; e = e.next) {
K k;
if ((k = e.key) == key || (e.hash == h && key.equals(k)))
return e.value;
}
}
return null;
}
get操作的高效之處在於整個get過程不需要加鎖，除非讀到的值是空的纔會加鎖重讀，那麼我們看下ConcurrentHashMap是如何做到get不加鎖的吧：原因是它的get方法裏將要使用的共享變量都定義成volatile，在get操作裏只需要讀不需要寫共享變量，所以可以不用加鎖。之所以不會讀到過期的值，是因爲根據JMM的先行發生原則，對volatile字段的寫入操作優先於讀操作，即使兩個線程同時修改和獲取volatile變量，get操作最終也只會拿到最新的值。
size操作：
我們要統計ConcurrentHashMap裏元素的大小，就必須統計所有的分區Segment裏面元素的總和，但是如果我們在統計每個Segment裏面元素總數的過程中，之前已經統計過得Segment又發生了更新，那麼之前統計的總數就失效了，所以最安全的做法是在統計每個Segment的時候統計好的Segment就將他的更新操作全部鎖住，等待全部Segment統計完畢再釋放，但是顯然這樣是不科學的，效率非常低下。
源碼如下：
/**
* 在累加count操作過程中，之前統計過的Segment發生變化的機率比較小，所以
* ConcurrentHashMap的做法是先嚐試2次不加鎖的方式來統計各個Segment大小，如果統計的過程中，
* 容器的count發生了變化，則再採用加鎖的方式來統計所有Segment的大小
* ConcurrentHashMap是如何判斷在統計的時候容器是否發生了變化呢？
* 使用modCount變量，在put , remove和clean方法裏操作元素前都會將變量modCount進行加1，
* 那麼在統計size前後比較modCount是否發生變化，從而得知容器的大小是否發生變化
*/
public int size() {
final Segment<K,V>[] segments = this.segments;
int size;
boolean overflow; // true if size overflows 32 bits
long sum; // sum of modCounts
long last = 0L; // previous sum
int retries = -1; // first iteration isn't retry
try {
for (;;) {
if (retries++ == RETRIES_BEFORE_LOCK) {
for (int j = 0; j < segments.length; ++j)
ensureSegment(j).lock(); // force creation
}
sum = 0L;
size = 0;
overflow = false;
for (int j = 0; j < segments.length; ++j) {
Segment<K,V> seg = segmentAt(segments, j);
if (seg != null) {
sum += seg.modCount;
int c = seg.count;
if (c < 0 || (size += c) < 0)
overflow = true;
}
}
if (sum == last)
break;
last = sum;
}
} finally {
if (retries > RETRIES_BEFORE_LOCK) {
for (int j = 0; j < segments.length; ++j)
segmentAt(segments, j).unlock();
}
}
return overflow ? Integer.MAX_VALUE : size;
}
景點五：ConcurrentHashMap的缺點
ConcurrentHashMap的缺點就是他最多隻能支持16個線程的併發，如果實際場景中，你需要啓動的線程的數量比較多，還是同樣會發生鎖競爭和等待的問題：
以上就是今天所講的ConcurrentHashMap的五大景點的所有內容，希望能對你有所幫助，通過短短十幾分鐘的閱讀，希望你能有所收穫！！！