【原创】够强！一行代码就修复了我提的Dubbo的Bug。

末蓝、 2023-06-27 11:29 20阅读 0赞

这是 why 技术的第 28 篇原创文章

之前在《[Dubbo][] 一致性哈希负载均衡的源码和 Bug，了解一下？》中写到了我发现了一个 Dubbo 一致性哈希负载均衡算法的 Bug。

对于解决方案我是这样写的：

`特别简单，把获取identityHashCode的方法从System.identityHashCode(invokers)修改为invokers.hashCode()即可。此方案是我提的issue里面的评论，这里System.identityHashCode和 hashCode之间的联系和区别就不进行展开讲述了，不清楚的大家可以自行了解一下。`

我说：**这里 System.identityHashCode 和 hashCode 之间的联系和区别就不进行展开讲述了，不清楚的大家可以自行了解一下。**

但是有读者在后台问我详细原因，我已经和他聊清楚了。

![www.wityx.com][] 再加上这个**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？\*\*我们[看看][Link 1] 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 下面的这个评论，

我才一下回过神来，原来一行代码就能代替我写的工具类了啊。而对于这个知识点，我之前其实是知道的。

我反思了一下自己为什么没有想到这个方案。

**其实就是对于已知道的知识点，掌握不够深刻导致的，没有达到融会贯通的地步。知其然，也知其所以然，可惜在需要使用的场景稍稍一变的情况下，就想不起来了。**

知道知识点，但是该用的时候却记不起来，这种情况其实挺常见的，那怎么解决呢？

**这篇文章就是我的解决方案，记录下来嘛。就像高中的时候人手一本的错题本，做错的题，不会的题都抄下来嘛。没事的时候翻一翻，总有下次碰到的时候。再次碰到时，就是"一雪前耻"的机会。**

好了。

才疏学浅，难免会有纰漏，如果你发现了错误的地方，还请你留言给我指出来，我对其加以修改。

感谢您的阅读，感谢您的关注。

以上。

[Dubbo]: http://www.wityx.com/tag/dubbo
[www.wityx.com]: https://user-gold-cdn.xitu.io/2020/1/6/16f79156ac23676e?w=283&h=270&f=png&s=70182
[Link 1]: https://www.wuliaokankan.cn