讀時加寫鎖，寫時加讀鎖，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日記 ，及時乾貨不錯過，公眾號致力於通過畫圖加上通俗易懂的語言講解技術，讓技術更加容易學習，回覆 面試 即可獲得一套面試真題。