dubbo的 protocol标签提供了三个参数 dispatcher,threads(默认为100)
和 threadpool来为我们自定义DUBBO协议下的线程模型，其中dubbo自定义了5个线程dispatcher：
Dispatcher
- all 所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。
- direct 所有消息都不派发到线程池，全部在Io线程上直接执行
- message 只有请求响应消息派发到线程池，其他连接断开事件，心跳等消息，直接在Io线程上执行。
- execution 只请求消息派发到线程池，不含响应和其他连接断开事件，心跳等消息，直接在Io线程上执行。
- connection 在Io线程上，将连接断开事件放入队里，有序 逐个执行，其他消息派发到线程池。
以及四个常用的threadpool ：:
fixed固定大小线程池，启动时建立线程，不关闭，一直持有。(缺省)cached缓存线程池，空闲一分钟自动删除，需要时重建。limited可伸缩线程池，但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起的性能问题。eager优先创建Worker线程池。在任务数量大于corePoolSize但是小于maximumPoolSize时，优先创建Worker来处理任务。当任务数量大于maximumPoolSize时，将任务放入阻塞队列中。阻塞队列充满时抛出RejectedExecutionException。(相比于cached:cached在任务数量超过maximumPoolSize时直接抛出异常而不是将任务放入阻塞队列)
DUBBO 官方文档给出的建议：
1：如果事件处理的逻辑能迅速完成，并且不会发起新的 IO 请求，比如只是在内存中记个标识，则直接在 IO 线程上处理更快，因为减少了线程池调度。:
2：但如果事件处理逻辑较慢，或者需要发起新的 IO 请求，比如需要查询数据库，则必须派发到线程池，否则 IO 线程阻塞，将导致不能接收其它请求。
3：如果用 IO 线程处理事件，又在事件处理过程中发起新的 IO 请求，比如在连接事件中发起登录请求，会报“可能引发死锁”异常，但不会真死锁
当然，Dispatcher 和 threadpool 都是可以扩展的，可以参考DUBBO文档的 消息派发扩展和线程池扩展，此外，dispatcher与threadpool是有联系的，
，dispatcher在获线程池时，如果没有threadpool扩展则线程池默认为 Executors.newCachedThreadPool(new NamedThreadFactory("DubboSharedHandler", true));
如果有threadpool扩展则使用拓展的线程池。
DUBBO默认的AllDispatcher的线程池获取逻辑如下：
