這篇文章，我們深入聊聊：讀寫鎖如何保證 HashMap 成為一個(gè)線程安全的容器。

圖片

1.編程范式例子

圖片

上圖展示了使用讀寫鎖對 HashMap 進(jìn)行操作的編程范式，核心要點(diǎn)：

• 單獨(dú)的類用于封裝對 HashMap 的讀、寫操作；
• 讀操作方法內(nèi)部，先獲取讀鎖，讀取數(shù)據(jù)之后，釋放讀鎖；
• 寫操作方法內(nèi)部，先獲取寫鎖，寫入成功之后，釋放寫鎖。

很多同學(xué)問我：”勇哥，假如讀鎖申請成功后，寫鎖會(huì)阻塞嗎 ？“ 或者 ”寫鎖申請成功后，讀鎖會(huì)被阻塞嗎？“ 。

答案是肯定的，讀寫必然互斥 。

筆者分別寫兩個(gè)簡單的例子，并展示堆棧圖，大家就可以一目了然。

2.讀鎖申請成功后，寫鎖會(huì)被阻塞

我們將 ReadWriteLockCache 的讀操作修改如下：

圖片

然后編寫 main 方法：

圖片

main 方法中，我們先后啟動(dòng)讀線程、寫線程 。

圖片

我們通過 IDEA 打印堆棧日志，發(fā)現(xiàn)：讀線程先獲取讀鎖，然后休眠 10 秒，這樣讀鎖就不會(huì)釋放，后面寫線程嘗試獲取寫鎖時(shí)，寫線程阻塞了。

3.寫鎖申請成功后，讀鎖會(huì)被阻塞

我們將 ReadWriteLockCache 的讀操作代碼還原，然后將寫操作修改如下：

圖片

然后編寫 Main 方法：

圖片

main 方法中，我們先后啟動(dòng)寫線程、讀線程 。

圖片

我們通過 IDEA 打印堆棧日志，發(fā)現(xiàn)：寫線程先獲取寫鎖，然后休眠 10 秒，這樣寫鎖就不會(huì)釋放，后面讀線程嘗試獲取讀鎖時(shí)，線程阻塞了。

4.使用 ConcurrentHashMap 是不是更簡單點(diǎn)

有的同學(xué)會(huì)問：使用 ConcurrentHashMap 是不是更簡單點(diǎn)嗎 ？

我們分兩個(gè)層面來說明：

1）讀寫鎖 + 多個(gè) HashMap

讀寫鎖可以操作多個(gè) HashMap ，每次寫操作需要同時(shí)變更多個(gè) HashMap ，為了保證其一致性，故需要加鎖，ConcurrentHashMap 并發(fā)容器在多線程環(huán)境下的線程安全也只是針對其自身，故從這個(gè)維度，選用讀寫鎖是必然的選擇 。

我們舉 RocketMQ NameServer 的經(jīng)典案例：

Broker 啟動(dòng)之后會(huì)向所有 NameServer 定期（每 30s）發(fā)送心跳包(路由信息)，NameServer 會(huì)定期掃描 Broker 存活列表，如果超過 120s 沒有心跳則移除此 Broker 相關(guān)信息，代表下線。

那么 NameServer 如何保存路由信息呢？

圖片

路由信息通過幾個(gè) HashMap 來保存，當(dāng) Broker 向 Nameserver 發(fā)送心跳包（路由信息），Nameserver 需要對 HashMap 進(jìn)行數(shù)據(jù)更新，但我們都知道 HashMap 并不是線程安全的，高并發(fā)場景下，容易出現(xiàn) CPU 100% 問題，所以更新 HashMap 時(shí)需要加鎖，RocketMQ 使用了  JDK 的讀寫鎖 ReentrantReadWriteLock 。

• 更新路由信息，操作寫鎖

圖片

• 查詢主題信息，操作讀鎖

圖片

2）讀寫鎖 + 1 個(gè) HashMap

假如我們僅僅使用讀寫鎖操作 1 個(gè) HashMap ，那么我們需要分析下 ConcurrentHashMap 的原理。

• JDK 8 之前

圖片

從圖中我們可以看出， ConcurrentHashMap 內(nèi)部進(jìn)行了 Segment 分段，Segment 繼承了 ReentrantLock，可以理解為一把鎖，各個(gè) Segment 之間都是相互獨(dú)立上鎖的，互不影響。

同一個(gè) Segment 的讀寫都需要加鎖，即落在同一個(gè) Segment 中的讀、寫操作是串行的，其讀的并發(fā)性低于讀寫鎖 + HashMap 的，

因此在 JDK 1.8 之前，ConcurrentHashMap 是落后于讀寫鎖 + HashMap 的結(jié)構(gòu)的。

•  JDK 1.8 及其后續(xù)版本

圖片

JDK 1.8 對 ConcurrentHashMap 代碼進(jìn)行了大幅優(yōu)化，存儲(chǔ)結(jié)構(gòu)與 HashMap 非常類似，同時(shí)引入了 CAS 機(jī)制（輕量級） 來解決并發(fā)更新。

因此，相比讀寫鎖操作 1 個(gè) HashMap， 使用 ConcurrentHashMap 更具性能優(yōu)勢。

5.總結(jié)

這篇文章，我們深入剖析：讀寫鎖如何保證 HashMap 成為一個(gè)線程安全的容器。

1）讀寫鎖編程范式

• 單獨(dú)的類用于封裝對 HashMap 的讀、寫操作；
• 讀操作方法內(nèi)部，先獲取讀鎖，讀取數(shù)據(jù)之后，釋放讀鎖；
• 寫操作方法內(nèi)部，先獲取寫鎖，寫入成功之后，釋放寫鎖。

2）兩個(gè)實(shí)驗(yàn)例子

• 讀鎖申請成功后，寫線程申請寫鎖會(huì)阻塞
• 寫鎖申請成功后，讀線程申請讀鎖會(huì)阻塞

我們用兩個(gè)實(shí)驗(yàn)突出了讀寫鎖的特性：讀讀不互斥，讀寫互斥，寫寫互斥 。

3）使用 ConcurrentHashMap 是不是更簡單點(diǎn)

• 假如需要操作 多個(gè) HashMap ，那么讀寫鎖更加有優(yōu)勢 ;
• 假如僅僅操作 1個(gè) HashMap  ,  建議使用  JDK 1.8 ConcurrentHashMap ，性能會(huì)更好。