我去,这是出BUG了呀!
这是why的第 115 篇原创文章
你好呀,我是why。
前两天在 Git 上闲逛的时候又不知不觉逛到 Dubbo 那里去了。
看了一下最近一个月的数据,社区活跃度还是很高的:
然后看了一下最新的 issue,大家提问都很积极。
其中看到了这样的一个 issue,发现有点意思:
https://github.com/apache/dubbo/issues/8055
于是写下这篇文章给你分享一下这个 BUG 和 BUG 背后的故事。
放心,就算你完全不懂 Dubbo,也不影响你了解这个 BUG。
先说一下,下文中提到的 Dubbo 代码,没有特别说明的地方,都是我从 git 上拉下来的 Master 分支上的代码
啥 BUG 啊?
先给你描述一个这个 BUG 是啥样的。
其实就是这个 issue 的作者写出来的:Dubbo 框架里面的 Filter 排序过程有问题,即使按照框架要求写好规则后,最终生成的 Filter 链并不是我们想要的。
那么完全不懂 Dubbo 的朋友可能就遇到了第一个问题:啥是 Filter 呢?
其实就是一个过滤器而已,和 web 服务里面过滤器在概念上没啥两样。而 Dubbo 有非常多的 Filter,这些 Filter 共同组成了一个 Filter 调用链。
引用官网上的一个调用链路图,在 Filter 的地方我框起来了:
可以看到 Filter 是 Dubbo 框架的一个非常核心的组成部分,很多很多的功能都是从 Filter 扩展出来的。
你要是还不明白也没关系,你只要知道有这样的一个 Filter 调用链就行了,链上的 Filter 各司其职,各干各的事儿。
好的,那么现在需求来了:
我现在要求链上的 Filter 的执行顺序是我能控制的,即我定义 Filter 的时候你得给我留个地方设置它的优先级。
听起来是很简单的一个需求,对吧?
我直接给你留个口子,让你输入 order 参数,不输入给个默认值,然后组装 Filter 链的时候根据 Order 排个序。
不是我吹牛,十分钟就能写完,中间还带着三分钟的摸鱼。
但是,就这么个需求出 BUG 了。
具体啥现象呢?
我这里把项目拉下来,基于官方的测试用例,改巴改巴,给你演示一下这个 BUG 的体现是啥。
在 Dubbo 里面有这样的一个注解:
org.apache.dubbo.common.extension.Activate
这里的 Order 就是做排序用的。简单演示一下,你看我现在有 5 个 Filter:
排序规则是 Order 越小的越先执行,那么这个 Filter 链的执行顺序应该是这样的:
Filter4 -> Filter3 -> Filter2 -> Filter1 -> Filter5
搞个测试案例,我们验证一下:
符合预期,没有任何毛病。
另外说明一下,官方的关于 Filter 的测试用例在这里,你有兴趣,源码拉下来就可以看:
org.apache.dubbo.common.extension.support.ActivateComparatorTest#testActivateComparator
不管是官方的案例,还是我自己写的案例,其中最关键的排序功能是这一行代码实现的:
Collections.sort(filters, ActivateComparator.COMPARATOR)
而这一行代码里面最关键的就是 ActivateComparator.COMPARATOR
这个东西。
这个东西就是 BUG 之源,不慌,等下再说。
那么为什么说它有 BUG 呢?
前面演示了正常的情况下,是符合预期的。
但是你看 Activate
注解,里面还有这样的两个东西:
before、after,含义是指定 Filter A 在 Filter B 之前或者之后执行。
但是被打上了 @Deprecated
注解,字段说明上也备注了:
Deprecated since 2.7.0
2.7.0 之后被废除。
那么就有点意思了,为啥被废除?
来,看个例子,还是刚刚的那个测试用例。
我就稍微的这么一改:
@Activate(before = "_2")
public class Filter5 implements Filter0{
}
改动点就是在 Filter5 上配置了:
@Activate(before = "_2")
含义就是 Filter5 在 “_2” 之前执行。
“_2” 是啥?
就是 Filter2 的一个映射而已:
那么问题就来了,作为一个正常的程序猿,自信的对 Filter5 进行了这个改动之后,他内心的想法一定是想要把这样的 Filter 链:
Filter4 -> Filter3 -> Filter2 -> Filter1 -> Filter5
修改为这样(Filter5 在 Filter2 之前执行):
Filter4 -> Filter3 -> Filter5 -> Filter2 -> Filter1
那么实际情况是怎样的呢?
来跑一把:
咋回事?这不是我预期的执行链啊?
是的,这就是 BUG 的表现。
咋回事啊?
到底是咋回事呢?
且听我给你分析一波。
上一小节我说了,问题出在排序算法上。
org.apache.dubbo.common.extension.support.ActivateComparator
来,一起看一下:
首先标号为 ① 的地方就是把 before、after、order 封装了一下,然后提供了几个比较的方法。你知道 ActivateInfo 这个实体里面有这些东西就行了,后面的代码会用到。
然后说说标号为 ② 的地方。
这个地方你别看挺长的,但是其实逻辑特别简单,当前对比的两个 filter 中的任何一个配置了 before、after 就会进入到标号为 ② 的部分的逻辑。
然后这里面的一坨逻辑是的这样的:
具体逻辑不细说了,等会给你来个直观的演示。
最后标号为 ③ 这个地方,有点意思,稍微多说几句。
能走到标号为 ③ 的地方,说明当前对比的两个 filter 都没有配置 after、before 这两个属性。直接对比 Order 就行了。
这个地方对 Order 相等的情况还做了一个特殊处理:
o1.getSimpleName().compareTo(o2.getSimpleName()) > 0 ? 1 : -1
如果 Order 相等,再比较类名(这是大部分的场景)。
这样做的原因也是保证排序的稳定性。
举个例子,比如这两 Filter,都没有指定 Order:
那如果我们去掉这个判断:
代码就变成了这样:
if (a1.order > a2.order) {
return 1
} else {
return -1
}
简化一下就是这样:
return a1.order > a2.order ? 1:-1
那么这一块的代码,整体就会变成这样:
这样仔细一看:咦,好像还能再优化一下。78 行和 80 行是一样的,所以可以去掉 78 行。
好的,经过这样的一番改造。
恭喜你,获得了一个老版本的代码:
左边是之前版本的代码,右边是现在 Master 分支的代码:
为什么会发生变化,必然是有原因的。
看一眼提交记录:
这次提交指向了编号为 7778 的提交:
https://github.com/apache/dubbo/pull/7778
而这次提交指向了编号为 7757 的 issue:
https://github.com/apache/dubbo/issues/7757
而这个 issue 在前面提到的编号为 8055 的 issue 里也提到了:
这个 issue 主要就是两张图。
第一张图是这样的:
在没有任何自定义 Filter,仅有官方原有的 Filter 的情况下,构建出来的 Filter 链,ExecuteLimitFilter 在 MonitorFilter 之前。
第二张图是这样的:
在加入了一系列自定义的 Filter(没有指定 Order)之后,ExecuteLimitFilter 就排在了 MonitorFilter 之后了。
至于这两个 Filter 排前排后的影响是什么,和文本关系不大,就不扩展了,你有兴趣的可以去看看对应的链接。
总之,导致上面截图的现象的原因就是因为这个判断逻辑,所以这样是不稳当的:
return a1.order > a2.order ? 1:-1
来个例子演示一下:
左边是测试用例,右边是排序规则,下面是输出结果。
从输出结果可以看到,最终的 Filter 链取决于 list 的添加顺序。
这也就是 7757 这个 issues 说的:
list 的遍历顺序会影响到排序的顺序。
因此,才会有了这样的一次提交:
好,现在我们把排序顺序改回来,同样的测试用例再跑一次,就稳定了:
眼睛尖的朋友可能还发现了一个问题。
这个地方还有一次提交:
第一种判断:return o1.getSimpleName().compareTo(o2.getSimpleName()) 第二种判断:return o1.getSimpleName().compareTo(o2.getSimpleName()) > 0 ? 1 : -1;
你说这是在干啥?
其实第一种判断还疏忽了这样的一种情况,包名不同但是类名相同的情况:
com.why.a.whyFilter com.why.b.whyFilter
这个时候 o1.getSimpleName().compareTo(o2.getSimpleName())
返回的是 0。
返回 0 会发生啥?
直接吞掉一个 Filter 你信不信?
比如你的集合是 HashSet,或者是 TreeMap。
这就巧了,Dubbo 用的就是 TreeMap。
来个测试用例演示一下。
如果采用第一种判断,最后 TreeMap 里面只有一个 Filter 了:
如果采用第二种判断,最后 TreeMap 里面会有两个 Filter :
细节,魔鬼都在细节里面。
哎呀,真的是防不胜防啊。
好了,比较器我就说完了,但是你发现没有,我到现在都还没给你说排序过程不稳定这个 BUG 到底是啥。
不仅没说,还给你引申了一个其他的 BUG 出来。
莫慌,这不是我还没想好怎么给你描述嘛。
这个过程其实比较复杂,涉及到 Timsort 排序方法,就这方法就得另起一篇文章才能说清楚。
所以,我换了一个思路,主要给你看比较的过程,至于这个过程背后的原因。
就是 Timsort 在搞鬼,欢迎你自己去探索一番。
那过程是啥呢?
我在比较方法的入口处加上这样的输出语句:
五个 Filter 是这样的:
测试用例是这样的:
@Test
public void whyTest(){
List<Class> filters = new ArrayList<>();
filters.add(Filter4.class);
filters.add(Filter3.class);
filters.add(Filter2.class);
filters.add(Filter1.class);
filters.add(Filter5.class);
Collections.sort(filters, ActivateComparator.COMPARATOR);
StringBuilder builder = new StringBuilder();
for (int i = 0; i < filters.size(); i++) {
builder.append(filters.get(i).getSimpleName()).append("->");
}
System.out.println(builder.toString());
}
输出的日志是这样的:
发现问题了没?
首先我很心机的控制了一下 list 的添加顺序:
这样前三次比较就能构建这样的 Filter 链:
Filter4->Filter3->Filter2->Filter1->
然后,Filter5 进来后先和 Filter1 比,发现其 Order 为 0 比 Filter1 的 -1 大,于是比较结束,得到这样的Filter 链:
Filter4->Filter3->Filter2->Filter1->Filter5->
整个过程中,Filter5 与 Filter2 完全没有发生任何比较的操作,也就更不涉及到 Filter5 里面的 before 标签了:
但是当我把 list 的添加顺序修改一下:
咦,就正确了,你就说神不神奇?
神奇吧?
为啥呢?
去看看 Timsort 的原理吧。
追根溯源
其实写到这里的我产生了一个疑问:
是谁,什么时候,引入了 after/before 机制?
因为这个机制我个人觉得出发点是挺好的,多一个配置的地方,把选择权留给用户。
但是在实际的使用中,却容易出现比较混乱的情况。
于是我看了一下提交记录:
这个注解最早是梁飞(就是 Dubbo 项目要的开创者之一)写出来的,而设计之初没有 before 和 after,但是有一个 match 和 mismatch。
然后在写出这个注解一天之后的凌晨 1 点 54 分,提交了一个方法级别的匹配:
这三个方法使用起来甚至比 before/after 更加复杂了。
于是一觉睡醒之后的 12:34 分,梁飞又删除了这三个配置:
两个月之后的 2012 年 5 月 8 日,加入了 after 和 before 配置:
然后就一直留在 Dubbo 源码里面,直到 6 年后的 2018 年 8 月 7 日,打上了不建议使用的注解:
并提到了这个 issue:
https://github.com/apache/dubbo/issues/2180
里面说:Dubbo 源码中没有使用 after 和 before,且排序是存在问题的。
于是这两个方法,在 2.7.0 版本之后,被标注为不建议使用,宣告了该方法的死亡。
我不知道 2012 年,梁飞为什么引入了这两个方法,我也曾想从他的代码提交记录上找到点蛛丝马迹,可惜没有。
但是,有了另外的一个想法:
当年梁飞引入这两个方法后,他写的比较器,是否考虑到了这样的情况呢?
于是我马上又看了比较器的代码提交记录:
org.apache.dubbo.common.extension.support.ActivateComparator
并且把他的代码拷贝了出来,用同样的测试用例跑了一下:
很遗憾,也有一样的问题。
或许,当年就不应该引入这两个方法。
大道至简,学 Spring 的 Order,就只有一个 Order:
然后我又突然想了另外一个框架:SofaRPC。
SofaRPC 和 Dubbo 和 HSF 之间有着千丝万缕的爱恨情仇,于是我去瞅了一眼 SofaRPC 对应的地方:
com.alipay.sofa.rpc.ext.Extension
用于排序的,也就只是保留了 order。
这样比较器的代码就很简单了:
com.alipay.sofa.rpc.common.struct.OrderedComparator
另外,我顺便对比了一下梁飞最早写的比较器和现在最新的比较器的代码,功能完全一样,但是代码却差异较大:
不得不说,经过几次重构之后,最新的比较器的可读性高了很多。
我追踪了一下这个类的提交记录,也就看着这个类的一步步演化,其实算是一个比较好的代码重构的例子。
有兴趣的自己去翻一翻。
好了,就写到这了,打完收工。
荒腔走板
昨天荒过了啊:《我笑疯了!》
真的是太搞笑了,昨天发文之后,很多小伙伴说要去打卡。
那我就再多说几句。哈哈曲艺社在成都有两家分社:
东门店的环境怎么样我现在还不太清楚,但是峨影店是真的不错,可以早点去等着,在店里面逛逛,能拍出很有意境的、文艺的、老成都的照片。
他们说每晚的演出内容是不一样的,这我是不信的,我倒是要看看啥时候能把他们的段子给掏空了。
还有人问我炸洋芋是哪家?
这...
别人是个路边摊,我也是随机遇到的。只大概知道从地铁口出来之后的第一个路口处,具体方位我就还真说不清楚了。
反正美食只等有缘人,缘分到了自然会遇到的。
到时候说不定还可以偶遇哦。
最后说一句
好了,看到了这里安排个“一键三连” (转发、在看、点赞)吧,周更很累的,需要一点正反馈。
感谢您的阅读,我坚持原创,十分欢迎并感谢您的关注。
推荐👍 :就这?一个没啥卵用的知识点。
推荐👍 :我不服!这开源项目居然才888个星!?
推荐👍 :曝光一个网站,我周末就耗在上面了。
我是 why,一个主要写代码,经常写文章,偶尔拍视频的程序猿。
欢迎关注我呀。