下面是dubbo3的同步调用 dubbo 2.7.5和以后的版本也差不多是按照这个流程来
2.7.5之前的同步调用比较大的区别就是之前的版本没有ThreadlessExecutor 获取结果对象直接使用CompletableFuture.get方法获取 然后通过消费者线程池把结果放入到CompletableFuture中 唤醒业务线程 为什么不用CompletableFuture的get进行阻塞等待 然后唤醒处理后续流程 我理解是因为CompletableFuture里的内容是一个返回对象 而提供者返回的是一个原始消息模型还需要进行解析 无法放入到Future 因为模型不一致 所以需要使用ThreadlessExecutor 当唤醒以后 经过解析 再放入到future中 而且为了让收到消息后的处理让消费者线程进行处理 也需要依靠ThreadlessExecutor来实现
这块新版本之所以使用ThreadlessExecutor 核心是为了少用Consumer消费者线程池 也就是cache线程池 老的版本线程模型有个问题就是收到结果以后的处理会放入到消费者线程池里处理 当大量请求阻塞比较久 消费者响应结果非常多的时候 会导致消费者线程池也就是cache线程池非常多 容易导致内存溢出 之所以新版本异常场景也还是让消费者线程处理 而是直接结束 是为了后续流程能正常执行 比如remove存放id和feature的map
老的线程模型
线程池：
- 消费者业务线程池BizThread：执行业务代码
- 消费者IO线程池：netty的boss线程池 没有work线程池 boss线程池的EventLoopGroup大小为cpu核心数+1
- 消费者线程池Consumer：CachedThreadPool 默认参数核心线程数为0 最大线程数为2的32次方-1 默认为1分钟自动销毁
- 提供者IO线程池：netty的boss线程和work线程池 boss的EventLoopGroup大小为1 work的EventLoopGroup大小为cpu核心数+1
- 提供者业务线程池Dubbo Business Thread Pool：默认使用固定大小线程池 默认核心线程数和最大线程数都为200
\
\
新的线程模型
线程池：
- 消费者业务线程池BizThread：执行业务代码
- 消费者IO线程池：netty的boss线程池 没有work线程池 boss线程池的EventLoopGroup数量为cpu核心数+1
- 消费者线程池Consumer：CachedThreadPool 默认参数核心线程数为0 最大线程数为2的32次方-1 默认1分钟自动销毁 新的模型里 这个线程池只有在线程中断或者调用超时的时候才会使用不在正常流程里
- 提供者IO线程池：netty的boss线程和work线程池 boss的EventLoopGrou数量为1 work的EventLoopGroup数量为cpu核心数+1
- 提供者业务线程池Dubbo Business Thread Pool：默认使用固定大小线程池 默认核心线程数和最大线程数都为200
\
新老线程模型的核心区别就是新的线程模型把返回结果放入到feature这一步在业务线程池里执行 只有异常情况才会在消费者线程池里执行
实现就是通过加入ThreadlessExecutor来实现
\
\
参考地址
