Closed liyuntao closed 3 years ago
https://github.com/xuxueli/xxl-rpc/blob/1.6.0/xxl-rpc-core/src/main/java/com/xxl/rpc/core/remoting/net/impl/netty_http/server/NettyHttpServerHandler.java#L47
这里通过 ThreadPoolUtil 启动了一个默认(core=60, max-300, core线程不回收)的线程池来 serve 请求，但是里面几乎没有阻塞场景。基本是反射调用 core 包的业务执行器，然后提交任务到队列就结束了，而业务执行器也持有一个自己专属的线程池。
私以为这里的线程池可以大幅缩减默认线程数(core=1 就足够)，提升引入 xxl 执行器工程的整体资源利用率。
迫于没有投入太多时间看这里，我不确定这个 NettyServerHandler/NettyHttpServerHandler 在任何情况下整套执行逻辑都没有阻塞，倘若是这样或可以通过简单改动做到如此，这个线程池完全可以移除。
下图是我们业务容器中，通过 jstack 观看到的情况（全部线程都在 waiting 状态空等）
https://github.com/xuxueli/xxl-rpc/blob/1.6.0/xxl-rpc-core/src/main/java/com/xxl/rpc/core/remoting/net/impl/netty_http/server/NettyHttpServerHandler.java#L47
这里通过 ThreadPoolUtil 启动了一个默认(core=60, max-300, core线程不回收)的线程池来 serve 请求，但是里面几乎没有阻塞场景。基本是反射调用 core 包的业务执行器，然后提交任务到队列就结束了，而业务执行器也持有一个自己专属的线程池。
私以为这里的线程池可以大幅缩减默认线程数(core=1 就足够)，提升引入 xxl 执行器工程的整体资源利用率。
迫于没有投入太多时间看这里，我不确定这个 NettyServerHandler/NettyHttpServerHandler 在任何情况下整套执行逻辑都没有阻塞，倘若是这样或可以通过简单改动做到如此，这个线程池完全可以移除。
下图是我们业务容器中，通过 jstack 观看到的情况（全部线程都在 waiting 状态空等）