一个排序引发的BUG

你好呀，我是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());
}