![516d217a2e0f03c0113c7bee1a92c825.png](https://i-blog.csdnimg.cn/blog_migrate/1b1c2c2740166fa8c40d245841379bb9.jpeg)
Dubbo中线程池的应用还是比较广泛的,按照consumer端到provider的RPC的方向来看,consumer端的应用业务线程到netty线程、consuemr端dubbo业务线程池,到provider端的netty boss线程、worker线程和dubbo业务线程池等。这些线程各司其职相互配合,共同完成dubbo RPC服务调用,理解dubbo线程模型对于学习Dubbo原理很有帮助。
dubbo线程模型包括线程模型策略和dubbo线程池策略两个方面,下面就依次进行分析。
dubbo线程模型
Dubbo默认的底层网络通信使用的是Netty,服务提供方NettyServer使用两级线程池,其中EventLoopGroup(boss)
主要用来接收客户端的链接请求,并把完成TCP三次握手的连接分发给EventLoopGroup(worker)
来处理,注意把boss和worker线程组称为I/O线程,前者处理IO连接事件,后者处理IO读写事件。
设想下,dubbo provider端的netty IO线程是如何处理业务逻辑呢?如果处理逻辑较为简单,并且不会发起新的I/O请求,那么直接在I/O线程上处理会更快,因为这样减少了线程池调度与上下文切换的开销,毕竟线程切换还是有一定成本的。如果逻辑较为复杂,或者需要发起网络通信,比如查询数据库,则I/O线程必须派发请求到新的线程池进行处理,否则I/O线程会被阻塞,导致处理IO请求效率降低。
那Dubbo是如何做的呢?
Dubbo中根据请求的消息类是直接被I/O线程处理还是被业务线程池处理,Dubbo提供了下面几种线程模型:
![c1f78c142051af5fc08ae35d9dcfdbe3.png](https://i-blog.csdnimg.cn/blog_migrate/c3aab985491a0ac5f114e930e165f75c.jpeg)
- all(AllDispatcher类):所有消息都派发到业务线程池,这些消息包括请求、响应、连接事件、断开事件等,响应消息会优先使用对于请求所使用的线程池。
- direct(DirectDispatcher类):所有消息都不派发到业务线程池,全部在IO线程上直接执行。
- message(MessageOnlyDispatcher类):只有请求响应消息派发到业务线程池,其他消息如连接事件、断开事件、心跳事件等,直接在I/O线程上执行。