Netty服务器老板和工人线程池大小

Question

如果我对Netty server的理解是正确的，那么主boss事件循环线程池（默认大小为2*AvailableProcessor）接受客户端连接，然后将请求处理工作卸载到工作线程。

现在，我的问题是，工作线程的线程池大小应该是多少？如果工作线程正在执行一些阻塞操作，例如等待网络调用响应，那么工作线程池是否应该足够大（例如200个线程）来处理并发客户端请求，因为每个工作线程都被阻塞以服务客户端请求？我看到大多数ServerBootstrap示例都显示工作线程池大小为2x可用性处理器，与主线程池大小相同。不会将并发客户端请求处理的数量限制为2x可用性处理器吗？

更让我困惑的是，我看到另一个线程池被称为处理程序线程池（EventExecutorGroup），并说这个线程池处理请求处理。那么工作线程池有什么用呢？

这三种类型的线程池在下面的示例中创建。

EventLoopGroup bossGroup = new NioEventLoopGroup(1);
EventLoopGroup workerGroup = new NioEventLoopGroup(10);
EventExecutorGroup handlerThread = new DefaultEventExecutorGroup(20);

若工作线程正在执行一些CPU密集型进程（与上例中等待网络调用响应相反），则工作线程将与主boss线程竞争。这种情况会不会使boss线程变慢，从而导致排队等待接受或拒绝的客户端连接？在这种情况下，我相信服务器的性能将与传统的阻塞服务器相同。你能谈谈你的想法吗？

Answer 1

现在，我的问题是，工作线程的线程池大小应该是多少？如果工作人员正在执行某些阻塞操作，例如等待网络呼叫响应

您不应该阻塞网络工作线程，尤其是对于网络I/O--这是使用非阻塞异步框架（如netty）的全部要点。也就是说，为了与像JDBC这样的同步/阻塞代码进行互操作，netty提供了一种使用EventExecutorGroup将此类执行卸载到单独线程池的方法。看看Netty文档中的这个片段：

 // Tell the pipeline to run MyBusinessLogicHandler's event handler methods
 // in a different thread than an I/O thread so that the I/O thread is not blocked by
 // a time-consuming task.
 // If your business logic is fully asynchronous or finished very quickly, you don't
 // need to specify a group.
 pipeline.addLast(group, "handler", new MyBusinessLogicHandler());

如果工作线程正在执行一些CPU密集型进程

这是一个更一般的问题，与netty并不完全相关，但如果您的工作负载是CPU密集型的，那么使用异步网络I/O框架可能不适合您。