也就是不论怎样，最终都会调用这个 received 方法，最终都会通过这个方法把对应调用编号的 DefaultFuture 对象从 FUTURE 这个 MAP 中移除。

上面这个任务怎么触发呢？

Dubbo 自己搞了个 HashedWheelTimer ，这是什么东西？

时间轮调度算法呀：

你发起一个请求，指定时间内没有返回结果，于是就取消（future.cancel）这个请求。

这个需求不就类似于你下单买个东西，30 分钟还没有支付，于是平台自动给你取消了订单吗？

时间轮，可以解决你这个问题。之前的这篇文章中有介绍：《面试时遇到『看门狗』脖子上挂着『时间轮』，我就问你怕不怕？》

一个 2.7.5 版本关于检查 Dubbo 超时的小知识点，送给大家。

验证编号

前面一直在强调，这个调用编号很重要。

所以为了让大家有个更加直观的认识，我截个简单的图，给大家验证一下这个编号确实是贯穿请求和响应的。

首先，改造一下我们的服务端：

先连续发 40 个请求到服务端，对于这些请求服务端都需要 10 秒的时间才能处理完成。

然后再发生一个特定请求到服务端，能即使返回。并在 39 行打上断点。

首先，看一下 DefaultFuture 里面的调用编号。

没看之前，你先猜一下，当前 debug 的这个请求的调用编号是多少？

是不是 40 号（编号从 0 开始）？

来验证一下：

所以在发送请求的地方，在 header 里面设置调用编号为 40：

然后看一下响应回来之后，对应的调用编号是否是 40：

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

感谢您的阅读，我坚持原创，十分欢迎并感谢您的关注。

我是 why，一个被代码耽误的文学创作者，不是大佬，但是喜欢分享，是一个又暖又有料的四川好男人。