一、讀寫鎖的介紹

上一篇文章：《??年底了我裁完兄弟自己也離職了，復(fù)習(xí)了Java鎖的底層準(zhǔn)備面試...??》，聊了一下java并發(fā)包的公平鎖和非公平鎖。

這篇文章來聊一下讀寫鎖。所謂的讀寫鎖，就是將一個鎖拆分為讀鎖和寫鎖兩個鎖，然后你加鎖的時候，可以加寫鎖，也可以加讀鎖。如下面代碼所示：

如果有一個線程加了寫鎖，那么其他線程就不能加寫鎖了，同一時間只能允許一個線程加寫鎖。因為加了寫鎖就意味著有人要寫一個共享數(shù)據(jù)，那同時就不能讓其他人來寫這個數(shù)據(jù)了。

同時如果有線程加了寫鎖，其他線程就不能加讀鎖了，因為既然都有人在寫數(shù)據(jù)了，你其他人當(dāng)然不能來讀數(shù)據(jù)了！

如果有一個線程加了讀鎖，別的線程是可以隨意同時加讀鎖的，因為只是有線程在讀數(shù)據(jù)而已，此時別的線程也是可以來讀數(shù)據(jù)的！

同理，如果一個線程加了讀鎖，此時其他線程是不可以加寫鎖的，因為既然有人在讀數(shù)據(jù)，那就不能讓你隨意來寫數(shù)據(jù)了！

好了！這個就是初步介紹一下讀寫鎖的使用方法，相信很多同學(xué)應(yīng)該之前都知道了，因為這個是java開發(fā)中非?；A(chǔ)的一塊知識。

二、微服務(wù)注冊中心的讀寫鎖優(yōu)化

現(xiàn)在進入主題，我們主要聊一下微服務(wù)注冊中心里面的讀寫鎖優(yōu)化。

為什么要聊一下這個問題呢？

因為如果你出去面試，很可能被問到讀寫鎖的問題，此時你可以自然而然的帶出來，你之前了解過Spring Cloud微服務(wù)技術(shù)架構(gòu)，同時對里面的微服務(wù)注冊中心的注冊表讀寫鎖優(yōu)化有一些自己的感悟和看法。

這樣的話，相比于你簡單的給面試官聊聊讀寫鎖的基本概念和使用方法，要增色不少！

好，了解了這些前置知識之后，我們正式開始。

先來看看下面的圖，現(xiàn)在我們知道一個微服務(wù)注冊中心（可以是Eureka或者Consul或者你自己寫的一個微服務(wù)注冊中心），他肯定會在內(nèi)存中有一個服務(wù)注冊表的概念。

這個服務(wù)注冊表中就是存放了各個微服務(wù)注冊時發(fā)送過來的自己的地址信息，里面保存了每個服務(wù)有多少個服務(wù)實例，每個服務(wù)實例部署在哪臺機器上監(jiān)聽哪個端口號，主要是這樣的一些信息。

OK，那現(xiàn)在問題來了，這個服務(wù)注冊表的數(shù)據(jù)，其實是有人讀也有人寫的。

舉個例子，比如有的服務(wù)啟動的時候會來注冊，此時就會修改服務(wù)注冊表的數(shù)據(jù)，這個就是寫的過程。

接著，別的服務(wù)也會來讀這個服務(wù)注冊表的數(shù)據(jù)，因為每個服務(wù)都需要感知到其他服務(wù)在哪些機器上部署。

所以，這個內(nèi)存里的服務(wù)注冊表數(shù)據(jù)，天然就是有讀寫并發(fā)問題的！可能會有多個線程來寫，也可能會有多個線程來讀！

如果你對同一份內(nèi)存中的注冊表數(shù)據(jù)不加任何保護措施，那么可能會有多線程并發(fā)修改共享數(shù)據(jù)的問題，可能導(dǎo)致數(shù)據(jù)錯亂，對吧？

上述過程，大家看看下面的圖，就明白了。

此時，如果對服務(wù)注冊表的服務(wù)注冊和讀取服務(wù)注冊表的方法，都加一個synchronized關(guān)鍵字，是不是就可以了呢？

或許你會想，加上synchronized，直接讓所有線程對服務(wù)注冊表的讀寫操作，全部串行化。那不就可以保證內(nèi)存中的服務(wù)注冊表數(shù)據(jù)安全了嗎？

下面是一段偽代碼，大家來感受一下：

在上面的代碼中直接給寫（服務(wù)注冊）和讀（讀取服務(wù)注冊表）兩個方法，都暴力的加上了synchronized關(guān)鍵字，確實是可以保證服務(wù)注冊表的數(shù)據(jù)不錯亂，但是這樣肯定是不太合適的。

因為這么搞的話，相當(dāng)于是所有的線程讀寫服務(wù)注冊表數(shù)據(jù)，全部串行化了。

大家思考一下，我們想要的效果是什么？其實不就是在有人往服務(wù)注冊表里寫數(shù)據(jù)的時候，就不讓其他人寫了，同時也不讓其他人讀！

然后，有人在讀服務(wù)注冊表的數(shù)據(jù)的時候，其他人都可以隨便同時讀，但是此時不允許別人寫服務(wù)注冊表數(shù)據(jù)了！

對吧，我們想要的，其實不就是這個效果嗎？

想清楚了這點，我們就不應(yīng)該暴力的加一個synchronized，讓所有讀寫線程全部串行化，那樣會導(dǎo)致并發(fā)性非常的低。

大家看看下面的圖，我們想要的第一個效果：一旦有人在寫服務(wù)注冊表數(shù)據(jù)，我們加個寫鎖，此時別人不能寫，也不能讀。

那么如果有人在讀數(shù)據(jù)呢？此時就可以讓別人都可以讀，但是不允許任何人寫。大家看下面的圖。

關(guān)鍵點來了，這樣做有什么好處呢？其實大部分時候都是讀操作，所以使用讀鎖可以讓大量的線程同時來讀數(shù)據(jù)，不需要阻塞不需要排隊，保證高并發(fā)讀的性能是比較高的。

然后?少量的時候是有服務(wù)上線要注冊數(shù)據(jù)，寫數(shù)據(jù)的場景是比較少的，此時寫數(shù)據(jù)的時候，只能一個一個的加寫鎖然后寫數(shù)據(jù)，同時寫數(shù)據(jù)的時候就不允許別人來讀數(shù)據(jù)了。

所以讀寫鎖是非常適合這種讀多寫少的場景的。

另外，我們能不能盡量在寫數(shù)據(jù)的期間還保證可以繼續(xù)讀數(shù)據(jù)呢？大量加讀鎖的時候，會阻塞人家寫數(shù)據(jù)加寫鎖過長時間，這種情況能否避免呢？

最后看下上面那段偽代碼如果用讀寫鎖來優(yōu)化是怎么樣的？?