另外一个 bug
回到最开始的地方，我为什么会在写 LFU 的时候联想到 Dubbo 呢？
因为在 2.7.7 这个版本发布的时候，我就关注到了它。
而当时关注到它的原因并不是 LFU ，而是新增了一种负载均衡策略：
于是我把之前的文章进行了汇总，写下了这篇文章：
而其中一致性哈希负载均衡策略，我在实践的时候也发现了一个 bug。
其实这个 bug 也是一个必现的 bug，为什么没有被爆出来的原因，我想是因为当前的版本使用的人不多，而使用一致性哈希负载均衡策略的就更少了，甚至没有。
这个 bug 具体是这样的：
我已经知道了在一致性哈希算法中的这行代码就是导致 bug 的原因：
System.identityHashCode(invokers)
甚至我也知道了，这行代码导致 bug 的原因是 invokers 这个集合的地址变了。
这个集合里面，放的就是服务提供者列表。
集合里面的服务者列表其实并没有变化，只是每次都用了一个新的 list 来装这些服务提供者。
而为什么每次都用一个新的 list 来装，我也找到了：
问题就出在 TagRouter 中：
org.apache.dubbo.rpc.cluster.router.tag.TagRouter#filterInvoker
基本上到这里，也就明确原因了。
但是我前面说了，更高一级的是了解这个框架的前世今生。
问题出在 TagRouter，那么这个 TagRouter 怎么来的呢？
如果了解 Dubbo 2.7.x 版本新特性的朋友可能知道，标签路由是 Dubbo2.7 引入的新功能。
巧就巧在我还真的清楚这个地方的来龙去脉。
因为我的第一篇技术文章就是写的 Dubbo 2.7 新特性，当时进行了一个了解。
没想到一年多以后，竟然还呼应上了。
而这个 bug，其实也是一行代码就能修复；
而我当时为什么没有去修复呢？
因为最开始找到这个 bug 的时候，我想到的解决方案是写个工具类。
思路也是只关心 List 里面的元素，而不关心 List 这个容器，但是实现方式比较复杂，改动点较多，还需要写一个工具类。
当时就没动手，想着先提个 issue 放着，有时间了再弄。
结果，没想到 issue 放上去的当天就有人回复并了一个我没有想到的解决方案：
看到这个回复的时候，我才一下回过神来，原来一行代码就能代替我写的工具类了啊。
而对于其中涉及到的知识点，我是知道的。
我反思了一下自己为什么没有想到这个方案。
其实就是对于已知道的知识点，掌握不够深刻导致的，没有达到融会贯通的地步。
知其然，也知其所以然，可惜在需要使用的场景稍稍一变的情况下，就想不起来了。
知道知识点，但是该用的时候却记不起来，这种情况其实挺常见的，那怎么解决呢？
于是我写下了这篇文章：
这篇文章就是我的解决方案，记录下来嘛。
就像高中的时候人手一本的错题本，做错的题，不会的题都抄下来嘛。没事的时候翻一翻，总有下次碰到的时候。再次碰到时，就是“一雪前耻”的机会。
