Dubbo 2.7.5在线程模型上的优化

文章中说这是Dubbo的一个里程碑式的版本。

在阅读了相关内容后，我发现这确实是一个里程碑式的跨域，对于Dubbo坎坷的一生来说，这是展现其强大的生命力和积极探索精神的一个版本。

强大的生命力体现在新版本发布后众多的或赞扬、或吐槽的社区反馈。

探索精神体现在Dubbo在多语言和协议穿透性上的探索。

在文章中列举了9大改造点，本文仅介绍2.7.5版本中的一个改造点：优化后的消费端线程模型。

本文大部分源码为2.7.5版本，同时也会有2.7.4.1版本的源码作为对比。

官网上的介绍

在介绍优化后的消费端线程模型之前，先简单的介绍一下Dubbo的线程模型是什么。

直接看官方文档中的描述，Dubbo官方文档是一份非常不错的入门学习的文档，很多知识点都写的非常详细。

可惜，在线程模型这块，差强人意，寥寥数语，图不达意：

官方的配图中，完全没有体现出线程"池"的概念，也没有体现出同步转异步的调用链路。仅仅是一个远程调用请求的发送与接收过程，至于响应的发送与接收过程，这张图中也没有表现出来。

所以我结合官方文档和2.7.5版本的源码进行一个简要的介绍，在阅读源码的过程中你会发现：

在客户端，除了用户线程外，还会有一个线程名称为DubboClientHandler-ip:port的线程池，其默认实现是cache线程池。

上图的第93行代码的含义是，当客户端没有指定threadpool时，采用cached实现方式。

上图中的setThreadName方法，就是设置线程名称：

org.apache.dubbo.common.utils.ExecutorUtil#setThreadName

可以清楚的看到，线程名称如果没有指定时，默认是DubboClientHandler-ip:port。

在服务端，除了有boss线程、worker线程（io线程），还有一个线程名称为DubboServerHandler-ip:port的线程池，其默认实现是fixed线程池。

启用线程池的dubbo.xml配置如下：

<dubbo:protocol name="dubbo" threadpool="xxx"/>

上面的xxx可以是fixed、cached、limited、eager，其中fixed是默认实现。当然由于是SPI，所以也可以自行扩展：

所以，基于最新2.7.5版本，官方文档下面红框框起来的这个地方，描述的有误导性：

从SPI接口看来，fixed确实是缺省值。

但是由于客户端在初始化线程池之前，加了一行代码（之前说的93行），所以客户端的默认实现是cached，服务端的默认实现是fixed。

我也看了之前的版本，至少在2.6.0时（更早之前的版本没有查看），客户端的线程池的默认实现就是cached。

关于Dispatcher部分的描述是没有问题的：

Dispatcher部分是线程模型中一个比较重要的点，后面会提到。

这里配一个稍微详细一点的2.7.5版本之前的线程模型，供大家参考：

图片来源:https://github.com/apache/dubbo/issues/890

2.7.5之前的线程模型的问题

那么改进之前的线程模型到底存在什么样的问题呢？

在《Dubbo 发布里程碑版本，性能提升30%》一文中，是这样描述的：

对 2.7.5 版本之前的 Dubbo 应用，尤其是一些消费端应用，当面临需要消费大量服务且并发数比较大的大流量场景时（典型如网关类场景），经常会出现消费端线程数分配过多的问题。

同时文章给出了一个issue的链接：

https://github.com/apache/dubbo/issues/2013