Dubbo（八）线程模型

线程池

Dubbo有两种线程池，第一种是I/O线程池，第二种是业务线程池。I/O线程池主要是收包发包，接收新的连接，业务线程则是执行我们的业务代码（调用接口的实现类）。I/O线程数默认是CPU的个数+1，业务线程数默认是200。

与其他半同步半异步的模型相似，Dubbo的业务线程池也配备了队列，不过队列容量的默认值是0，也即是不使用队列来缓存处理不过来的请求；关于这点，官方文档是这么解释的：“线程池队列大小，当线程池满时，排队等待执行的队列大小，建议不要设置，当线程池满时应立即失败，重试其它服务提供机器，而不是排队，除非有特殊需求”。在这点上，Dubbo则跟thrift的HsHaServer不同，后者使用了无限容量的队列来缓存所有来不及处理的请求，这种设计充满了风险，服务器面临大量请求时会因为队列耗尽内存而变得不稳定。

dispatcher

如果服务提供方的业务逻辑处理时间开销很少，能够快速完成，那么直接在I/O线程上处理会更快，因为这样减少了线程池调度与上下文切换的开销。但是如果业务逻辑比较长，比如访问数据库，则应该在业务线程中执行。针对不同请求分配不同的线程池的策略由参数dispatcher来指定，这个参数这隶属dubbo:protocol标签，它用来指定每种消息包是由I/O线程还是由业务线程来处理。

dispatcher有5个值：all, direct, message, execution, connection。

• all：所有消息都派发到业务线程池，这些消息包括请求、响应、连接事件、断开事件、心跳事件等。
• direct：所有消息都不派发到业务线程池，全部在I/O线程上直接执行。
• message：只有请求和响应消息派发到业务线程池，其他消息如连接、断开事件、心跳事件等，直接在I/O线程上执行。
• execution：只把请求类消息发送到业务线程处理，响应、连接事件、断开事件、心跳事件等消息直接在I/O线程上执行。
• connection：在I/O线程上将连接事件、断开事件放入队列，有序地逐个执行，其他消息派发到业务线程池处理。