這是 why 技術的第 28 篇原創文章

 

 

之前在《Dubbo 一致性雜湊負載均衡的原始碼和 Bug，瞭解一下？》中寫到了我發現了一個 Dubbo 一致性雜湊負載均衡演算法的 Bug。

對於解決方案我是這樣寫的：

特別簡單，把獲取identityHashCode的方法從System.identityHashCode(invokers)修改為invokers.hashCode()即可。此方案是我提的issue裡面的評論，這裡System.identityHashCode和 hashCode之間的聯絡和區別就不進行展開講述了，不清楚的大家可以自行了解一下。

我說：這裡 System.identityHashCode 和 hashCode 之間的聯絡和區別就不進行展開講述了，不清楚的大家可以自行了解一下。

但是有讀者在後臺問我詳細原因，我已經和他聊清楚了。

再加上這個BUG 已於近期修復了，且只用了一行程式碼就修復了，那我就寫一下解決方案，以及背後的原理。

即是對之前文章的一個補充，也是一個獨立的知識點。

所以本文主要是回答下面這三個問題：

1.什麼是 System.identityHashCode？

2.什麼是 hashCode？

3.為什麼一行程式碼就修復了這個 BUG？

注：本文 Dubbo 原始碼 2.7.4.1 版本。如果閱讀過《Dubbo 一致性雜湊負載均衡的原始碼和 Bug，瞭解一下？》可以更好的理解這篇文章。但是沒有讀過也不會影響閱讀。

前情回顧

先通過一個前情回顧，引出本文所要分享的內容。

Dubbo 一致性雜湊負載均衡演算法的設計初衷應該是如果沒有服務上下線的操作，後續請求根據已經對映好的雜湊環進行處理，不需要重新對映。

然而我在研究其原始碼時，我發現實際情況是即使在服務端沒有上下線操作的時候，一致性雜湊負載均衡演算法每次都需要重新進行 hash 環的對映。

實際情況與設計初衷不符。

於是給 Dubbo 提了一個 issue，地址如下：

https://github.com/apache/dubbo/issues/5429

以下內容是對該 issue 的詳細說明：

在 Dubbo 對應的原始碼中，只需要一行程式碼。就可以判斷是否有服務上下線的操作：

就是下面這一行程式碼：

int identityHashCode = System.identityHashCode(invokers);

通過判斷 invokers(服務提供方 List 集合)的 identityHashCode 是否發生了變化，從而判斷是否有服務上下線的操作。

但是這行程式碼，在Dubbo2.7.0 版本之後就失效了。

問題出在 Dubbo2.7.0 版本引入的新特性之一：標籤路由。

其對應的原始碼如下：

org.apache.dubbo.rpc.cluster.router.tag.TagRouter#filterInvoker

通過原始碼可以看出：在 TagRouter 中的 stream 操作，改變了 invokers，導致每次呼叫時其 System.identityHashCode(invokers)返回的值不一樣。

所以每次呼叫都會進行雜湊環的對映操作，在服務節點多，虛擬節點多的情況下一定會有效能問題。

該問題對應的 PR 連結如下：

https://github.com/apache/dubbo/pull/5440

修復方法也是特別簡單：把獲取 identityHashCode 的方法從 System.identityHashCode(invokers)修改為 invokers.hashCode()即可。如下圖所示：

為什麼一行程式碼就能修復？

為什麼把獲取 identityHashCode 的方法從 System.identityHashCode(invokers)修改為 invokers.hashCode()就可以了呢？

要回答這個問題，我們首先得明白什麼是 identityHashCode？什麼是 hashCode？

**什麼是 identityHashCode？**我們看看 API 裡面的註釋：

返回與預設方法 hashCode()返回的給定物件相同的雜湊碼，無論給定物件的類是否覆蓋了 hashCode()。空引用的雜湊碼為零。

另外關於 identityHashCode 還有下面的三條規則：

1.所以如果兩個物件 A == B，那麼 A、B 的 System.identityHashCode() 必定相等；

2.如果兩個物件的 System.identityHashCode() 不相等，那他們必定不是同一個物件；

3.但是如果兩個物件的 System.identityHashCode()相等，並不保證 A==B，因為 identityHashCode 的底層實現是基於一個偽隨機數實現的。

什麼是 hashCode？ 大家應該都比較熟了，還是看 API 上的註釋：

再結合下面兩個示例程式碼，深入理解。

示例一：WhyHashCodeDto沒有重寫 hashCode()方法，所以 identityHashCode 和 hashCode 的值是一樣的：

示例二：如下所示，String 是重寫了 hashCode()的方法，所以在下面的例子中 identityHashCode 不等於 hashCode：

帶入場景

有了前面的知識鋪墊，我們就可以回到 Dubbo 的一致性雜湊演算法的場景中去了。

在 PR 中有一行註釋是這樣寫的：

using the hashcode of list to compute the hash only pay attention to the elements in the list

我們應該只注意 list 裡面的元素就可以了。 而這個 list 裡面的元素，就是一個個的服務提供方。

所以，在 Dubbo 的一致性雜湊演算法的場景中，我們只需要關心 List 裡面的服務提供方是否有上下線的操作，而不關心這個 List 是否每次都是新的。

我們再回到原始碼中，結合原始碼，然後簡化原始碼：

把上面的原始碼抽離一下，簡化一下，如下：

filterInvoker 方法是根據條件過濾 invokers，並返回一個 List。而我傳入的條件是，過濾出 invokers 中 invoker 大於 0 的資料：

filterInvoker(invokers, invoker -> invoker > 0);

執行結果如下：

可以看到經過 filterInvoker 方法後，由於集合中所有的元素都滿足條件，所以過濾前後，集合中的元素並沒有發生變化，導致 hashCode 沒有變化。但是由於裝元素的容器(集合)已經不是原來的容器了，所以 identityHashCode 發生了變化。

"因為集合中的元素沒有發生變化，導致 hashCode 沒有變化。"這句話的理由是什麼？

因為 List 重寫了 hashCode()方法，其算出的 hashCode 只和 list 中的元素相關：

經過 filterInvoker 方法後元素還是【1,2,3】，與過濾之前一樣，所以 hashCode 沒有變。

"由於裝元素的容器(集合)已經不是原來的容器了，所以 identityHashCode 發生了變化。"這句話的理由又是什麼？

可以看到在原始碼中，Collectors.toList()方法會 new List。所以都是新的，那麼每次的 identityHashCode 必不相同。

上面的示例程式碼，模擬的是沒有服務上下線的操作。

接下來，我們模擬一下服務下線的場景：

這次傳入的過濾條件為，過濾出 invokers 中 invoker 大於 1 的資料：

filterInvoker(invokers, invoker -> invoker > 1);

輸出結果如下：

可以看到，過濾後的集合中只有【2,3】了，所以 hashCode 發生了變化。

上面的示例在 Dubbo 的一致性雜湊演算法的場景中相當於 1 號伺服器下線了，服務列表發生了變化，需要重新進行雜湊環的對映。

對應原始碼如下(PR 提交的原始碼)：

因為在標號為 ① 處得到的 invokersHashCode 和之前的不一樣了，所以在標號為 ② 處判斷條件為真，進入標號為 ③ 的程式碼處，重新進行 Hash 環的對映，並選擇某個虛擬節點執行該請求。

通過上面模擬的兩個示例，再結合下面的原始碼：

也就回答了為什麼把上圖中編號為 ① 處的程式碼替換為標號為 ② 的程式碼，這一行程式碼就能修復這個 Bug，核心思想就是隻關心 List 集合裡面的元素變化，而不關心 List 集合容器是否發生變化。

最後說一句

最開始找到這個 BUG 的時候，我自己也是有一套解決方案的。思路也是隻關心 List 裡面的元素，而不關心 List 這個容器，但是實現方式比較複雜，改動點較多，還需要寫一個工具類。

但是看到 issue 下面的這個評論，

我才一下回過神來，原來一行程式碼就能代替我寫的工具類了啊。而對於這個知識點，我之前其實是知道的。

我反思了一下自己為什麼沒有想到這個方案。

其實就是對於已知道的知識點，掌握不夠深刻導致的，沒有達到融會貫通的地步。知其然，也知其所以然，可惜在需要使用的場景稍稍一變的情況下，就想不起來了。

知道知識點，但是該用的時候卻記不起來，這種情況其實挺常見的，那怎麼解決呢？

這篇文章就是我的解決方案，記錄下來嘛。就像高中的時候人手一本的錯題本，做錯的題，不會的題都抄下來嘛。沒事的時候翻一翻，總有下次碰到的時候。再次碰到時，就是"一雪前恥"的機會。

好了。

才疏學淺，難免會有紕漏，如果你發現了錯誤的地方，還請你留言給我指出來，我對其加以修改。

感謝您的閱讀，感謝您的關注。

以上。

歡迎關注公眾號【why 技術】,堅持輸出原創。願你我共同進步。

相關推薦