讀時加寫鎖，寫時加讀鎖，Eureka可真的會玩

大家好，我是三友~~

在對于讀寫鎖的認識當中，我們都認為讀時加讀鎖，寫時加寫鎖來保證讀寫和寫寫互斥，從而達到讀寫安全的目的，但是就在我翻Eureka原始碼的時候，發現Eureka在使用讀寫鎖時竟然是在讀時加寫鎖，寫時加讀鎖，這波操作屬實震驚到了我，于是我就花了點時間研究了一下Eureka的這波操作，

Eureka服務注冊實作類

眾所周知，Eureka作為一個服務注冊中心，肯定會涉及到服務實體的注冊和發現，從而肯定會有服務實體寫操作和讀操作，這是每個注冊中心最基本也是最核心的功能，

如上圖，AbstractInstanceRegistry是注冊中心的服務注冊核心實作類，這里面保存了服務實體的資料，封裝了對于服務實體注冊、下線、讀取等核心方法，

這里講解一下這個類比較重要的成員變數

服務注冊表

private final ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry= new ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>>();

注冊表就是存盤的服務實體的資訊，Eureka是使用ConcurrentHashMap來進行保存的，鍵值是服務的名稱，值為服務的每個具體的實體id和實體資料的映射，所以也是一個Map資料結構，InstanceInfo就是每個服務實體的資料的封裝物件，

服務的上線、下線、讀取其實就是從注冊表中讀寫資料，

最近變動的實體佇列

private ConcurrentLinkedQueue<RecentlyChangedItem> recentlyChangedQueue = new ConcurrentLinkedQueue<>();

recentlyChangedQueue保存了最近變動的服務實體的資訊，如果有服務實體的變動發生，就會將這個服務實體封裝到RecentlyChangedItem中，存到recentlyChangedQueue中，

什么叫服務實體發生了變動，舉個例子，比如說，有個服務實體來注冊了，這個新添加的實體就是變動的實體，

所以服務注冊這個操作就會有兩步操作，首先會往注冊表中添加這個實體的資訊，其次會給這個實體標記為新添加的，然后封裝到RecentlyChangedItem中，存到recentlyChangedQueue中，

同樣的，服務實體狀態的修改、洗掉（服務實體下線）不僅會操作注冊表，同樣也會進行標記，封裝成一個RecentlyChangedItem并添加到recentlyChangedQueue中，

所以從這分析也可以看出，注冊表的寫操作同時也會往recentlyChangedQueue中寫一條資料，這句話很重要，

后面本文提到的注冊表的寫操作都包含對recentlyChangedQueue的寫操作，

讀寫鎖

private final ReentrantReadWriteLock readWriteLock = new ReentrantReadWriteLock();
private final Lock read = readWriteLock.readLock();
private final Lock write = readWriteLock.writeLock();

讀寫鎖就不用說了，JDK提供的實作，

讀寫鎖的加鎖場景

上面說完了AbstractInstanceRegistry比較重要的成員變數，其中就有一個讀寫鎖，也是本文的主題，所以接下來看看哪些操作加讀鎖，哪些操作加寫鎖，

加讀鎖的場景

1、服務注冊

服務注冊就是在注冊表中添加一個服務實體的資訊，加讀鎖，

2、服務下線

服務下線就是在注冊表洗掉這個服務實體的資訊，服務下線的方法最后是呼叫internalCancel實作的，而internalCancel是加的讀鎖，所以服務實體下線的時候加了讀鎖，

3、服務驅逐

什么叫服務驅逐，很簡單，就是服務端會定時檢查每個服務實體是否有向服務端發送心跳，如果服務端超過一定時間沒有接收到服務實體的心跳資訊，那么就會認為這個服務實體不可用，就會自動將這個服務實體從注冊表洗掉，這就是叫服務驅逐，

服務驅逐是通過evict方法實作的，這個方法最終也是呼叫服務下線internalCancel方法來實作驅逐的，

所以服務驅逐，其實也是加讀鎖的，因為最后是呼叫internalCancel方法來實作的，而internalCancel方法就是加的讀鎖，

4、更新服務狀態

服務實體的狀態變動了，進行更新操作，也是加的讀鎖

5、洗掉服務狀態

將服務的狀態刪了，也是加的讀鎖，

這里都是對于注冊表的寫操作，所以進行這些操作的同時也會往recentlyChangedQueue中寫一條資料，只不過方法太長，代碼太多，這里就沒有截出來，

加寫鎖的場景

獲取增量的服務實體的資訊，

所謂的增量資訊，就是回傳最近有變動的服務實體，而recentlyChangedQueue剛剛好保存了最近的服務實體的資訊，所以這個方法的實作就是遍歷recentlyChangedQueue，取出最近有變動的實體，回傳，所以保存最近變動的實體，其實是為了增量拉取做準備的，

加鎖總結

這里我總結一下讀鎖和寫鎖的加鎖場景：

• 加讀鎖： 服務注冊、服務下線、服務驅逐、服務狀態的更新和洗掉
• 加寫鎖：獲取增量的服務實體的資訊

讀寫鎖的加鎖疑問

上一節講了Eureka中加讀鎖和寫鎖的場景，有細心的小伙伴可能會有疑問，加讀鎖的場景主要涉及到服務注冊表的增刪操作，也就是寫操作；而加寫鎖的場景是一個讀的操作，

這不是很奇怪么，不按套路出牌啊，別人都是寫時加寫鎖，讀時加讀鎖，Eureka剛好反過來，屬實是真的會玩，

寫的時候加的讀鎖，那么就說明可以同時寫，那會不會有執行緒安全問題呢？

答案是不會有安全問題，

我們以一個服務注冊為例，一個服務注冊，涉及到注冊表的寫操作和recentlyChangedQueue的寫操作，

注冊表本身就是一個ConcurrentHashMap，執行緒安全的map，注冊表的值的Map資料結構，其實也是一個ConcurrentHashMap，如圖，

通過原始碼可以發現，其實也是放入的值也是一個ConcurrentHashMap，所以注冊表本身就是執行緒安全的，所以對于注冊表的寫操作，本身就是安全的，

再來看一下對于recentlyChangedQueue，它本身就是一個ConcurrentLinkedQueue，并發安全的佇列，也是執行緒安全的，

所以單獨對注冊表和recentlyChangedQueue的操作，其實是執行緒安全的，

到這里更加迷糊了，本身就是執行緒安全的，為什么要加鎖呢，而且對于寫操作，還加的是讀鎖，這就導致可以有很多執行緒同時去寫，對于寫來說，相當加鎖加了個寂寞，

帶著疑惑，接著往下看，

Eureka服務實體的拉取方式和hash對比機制

拉取方式

Eureka作為一個注冊中心，客戶端肯定需要知道服務端道理存了哪些服務實體吧，所以就涉及到了服務的發現，從而涉及到了客戶端跟服務端資料的互動方式，pull還是push，如果有不清楚pull和push的機制，可以看一下RocketMQ的push消費方式實作的太聰明了這篇文章，里面有交代什么是pull還是push，

那么Eureka到底是pull還是push模式呢？這里我就不再賣關子了，其實是一種pull模式，也就是說客戶端會定期從服務端拉取服務實體的資料，并且Eureka提供了兩種拉取方式，全量和增量，

1、全量

全量其實很好理解，就是拉取注冊表所有的資料，

全量一般發生在客戶端啟動之后第一次獲取注冊表的資訊的時候，就會全量拉取注冊表，還有一種場景也會全量拉取，后面會說，

2、增量

增量，前面在說加寫鎖的時候提到了，就是獲取最近發生變化的實體的資訊，也就是recentlyChangedQueue里面的資料，

增量相比于全量拉取的好處就是可以減少資源的浪費，假如全量拉取的時候資料壓根就沒有變動，那么白白浪費網路資源；但是如果是增量的話，資料沒有變動，那么就沒有增量資訊，就不會有資源的浪費，

在客戶端第一次啟動的全量拉取之后，定時任務每次拉取的就是增量資料，

增量拉取的hash對比機制

如果是增量拉取，客戶端在拉取到增量資料之后會多干兩件事：

• 會將增量資訊跟本地快取的服務實體進行合并
• 判斷合并后的服務的資料跟服務端的資料是不是一樣

那么如何去判定客戶端的資料跟服務端的資料是不是一樣呢？

Eureka是通過一種hash對比的機制來實作的，

當服務端生成增量資訊的時候，同時會生成一個代表這一刻全部服務實體的hash值，設定到回傳值中，代碼如下

所以增量資訊回傳的資料有兩部分，一部分是變動的實體的資訊，還有就是這一刻服務端所有的實體資訊生成的hash值，

當客戶端拉取到增量資訊并跟本地原有的老的服務實體合并完增量資訊之后，客戶端會用相同的方式計算出合并后服務實體的hash值，然后會跟服務端回傳的hash值進行對比，如果一樣，說明本次增量拉取之后，客戶端快取的服務實體跟服務端一樣，如果不一樣，說明兩邊的服務實體的資料不一樣，

這就是hash對比機制，通過這個機制來判斷增量拉取的時候兩邊的服務實體資料是不是一樣，

但是，如果發現了不一樣，那么此時客戶端就會重新從服務端全量拉取一次服務資料，然后將該次全量拉取的資料設定到本地的快取中，所以前面說的還有一種全量拉取的場景就在這里，原始碼如下

讀寫鎖的使用揭秘

前面說了增量拉取和hash對比機制，此時我們再回過頭仔細分析一下增量資訊封裝的兩步操作：

• 第一步遍歷recentlyChangedQueue，封裝增量的實體資訊
• 第二步生成所有服務實體資料對應的hash值，設定到增量資訊回傳值中

為什么要加鎖

假設不加鎖，那么對于注冊表和recentlyChangedQueue讀寫都可以同時進行，那么會出現這么一種情況

當獲取增量資訊的時候，在第一步遍歷recentlyChangedQueue時有2個變動的實體，注冊表總共有5個實體

當recentlyChangedQueue遍歷完之后，還沒有進行第二步計算hash值時，此時有服務實體來注冊了，由于不加鎖，那么可以同時操作注冊表和recentlyChangedQueue，于是注冊成功之后注冊表資料就變成了6個實體，recentlyChangedQueue也會添加一條資料

但是因為recentlyChangedQueue已經遍歷完了，此時不會在遍歷了，那么剛注冊的這個實體在此次獲取增量資料時就獲取不到了，但是由于計算hash值是通過這一時刻所有的實體資料來計算，那么就會把這個新的實體計算進去了，

這不完犢子了么，增量資訊沒有，但是全部實體資料的hash值有，那么就會導致客戶端在合并增量資訊之后計算的hash值跟回傳的hash值不一樣，就會導致再次全量拉取，白白浪費了本次增量拉取操作，

所以一定要加鎖，保證在獲取增量資料時，不能對注冊表進行改動，

為什么加讀寫鎖而不是synchronized鎖

這個其實跟Eureka沒多大關系，主要是讀寫鎖和synchronized鎖特性決定的，synchronized會使得所有的操作都是串行化，雖然也能解決問題，但是也會導致并發性能降低，

為什么寫時加讀鎖，讀時加寫鎖

現在我們轉過來，按照正常的操作，服務注冊等寫操作加寫鎖，獲取增量的時候加讀鎖，那么可以不可呢？

其實也是可以的，因為這樣注冊表寫操作和獲取的增量資訊讀操作還是互斥的，那么獲取的增量資訊還是對的，

那么為什么Eureka要反過來？

寫（鎖）寫（鎖）是互斥的，如果注冊表寫操作加了寫鎖，那么所有的服務注冊、下線、狀態更新都會串行執行，并發性能就會降低，所以對于注冊表寫操作加了讀鎖，可以提高寫的性能，

但是，如果獲取的增量讀的操作加了寫鎖，那豈不是讀操作都串行化了，那么讀的性能不是會變低么？而且注冊中心其實是一個讀多寫少的場景，為了提升寫的性能，浪費讀的性能不是得不償失么？

哈哈，其實對于這個讀操作性能低的問題，Eureka也進行了優化，那就是通過快取來優化了這個讀的性能問題，讀的時候先讀快取，快取沒有才會真正呼叫獲取增量的方法來讀取增量的資訊，所以最后真正走到獲取增量資訊的方法，請求量很低，

ResponseCacheImpl內部封裝了快取的操作，因為不是本文的重點，這里就不討論了，

總結

所以，通過上面的一步一步分析，終于知道了Eureka讀寫鎖的加鎖場景、為什么要加讀寫鎖以及為什么寫時加讀鎖，讀時加寫鎖，這里我再總結一下：

為什么加讀寫鎖

是為了保證獲取增量資訊的讀操作和注冊表的寫操作互斥，避免由于并發問題導致獲取到的增量資訊和實際注冊表的資料對不上，從而引發客戶端的多余的一次全量拉取的操作，

為什么寫時加讀鎖，讀時加寫鎖

其實是為了提升寫的性能，而讀由于有快取的原因，真正走到獲取增量資訊的請求很少，所以讀的時候就算加寫鎖，對于讀的性能也沒有多大的影響，

從Eureka對于讀寫鎖的使用也可以看出，一個技術什么時候用，如何使用都是根據具體的場景來判斷的，不能要一概而論，

往期熱門文章推薦

RocketMQ保姆級教程

三萬字盤點Spring/Boot的那些常用擴展點

RocketMQ的push消費方式實作的太聰明了

一網打盡異步神器CompletableFuture

@Async注解的坑，小心

掃碼或者搜索關注公眾號 三友的java日記 ，及時干貨不錯過，公眾號致力于通過畫圖加上通俗易懂的語言講解技術，讓技術更加容易學習，回復 面試 即可獲得一套面試真題，

標籤：其他

上一篇：Flink SQL 批模式下 ClickHouse 批量寫入

下一篇：Java 并發編程生產應用場景及實戰