Netty服务器主线程池和工作线程池大小

Question

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

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

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

这三种类型的线程池是在我遇到的示例中创建的，如下所示。

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

如果工作线程正在执行一些CPU密集型进程(而不是在上面的示例中等待网络调用响应(，则工作线程将与主boss线程发生冲突。这种情况不会使老板线程变慢，从而使排队等待接受或拒绝的客户端连接变慢吗？在这种情况下，我相信服务器的性能将与传统的阻塞服务器相同。你能谈谈你对此的看法吗？

Answer 1

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

您永远不应该阻塞netty工作线程，尤其是对于网络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框架可能不太适合您。