Question

我想了解Tomcat的BIO和NIO连接器的线程模型。我正在引用可以找到here的连接器的官方Tomcat 7文档。基于此，这就是我所怀疑的：

acceptorThread（s）：这是一个或最多2个线程（如文档中所述），它只负责接受进入的连接。这可以使用 acceptorThreadCount 进行配置，并建议多个机器可以使用两个以上 -
- 这是为什么？
- 这是否意味着同时打开的连接数量与服务器系统上允许的cpus数量与打开文件描述符数量成比例？
maxConnections（s）：
- 此设置与 acceptCount 之间的关系以及系统上打开的文件描述符的数量。
- 为什么NIO连接器（ 10000 ）的默认值比BIO（ = maxThreads ）高得多？
acceptCount ：当所有请求处理线程都忙时，这是请求的队列。
- 当请求被放入此队列时，是否也分配了一个文件描述符？或者仅当请求被主动处理时，它是否使用文件描述符？
请求处理线程：此池中的线程数由 maxThreads 和 minSpareThreads 属性配置。
- 此线程池与 acceptorThreads 之间的关系是什么？接受者线程是否会产生此池中的线程？
- 据我所知，NIO模型对请求处理线程的效率高于BIO模型。它如何实现这种效率？
- 正如我在各种来源中所读到的，NIO模型中的线程遵循每个请求的线程范例与BIO模型的每个连接的线程范例。此外，在NIO连接器模型中，实际请求处理被委托给不同的应用程序监视线程，而服务器的请求处理线程被返回到线程池，以接受更多连接。 那么，这是否意味着只有与服务器的连接属于 HTTP Keep-Alive 性质或者应用程序使用 Servlet时，NIO模型的好处才会显而易见3.0 的异步处理功能？
Servlet 3.0 ：
- 使用Servlet 3.0时，为了达到最佳效率，应用程序servlet线程池的大小（相对于连接器线程池大小）应该是多少？
- 当使用BIO模型和它们时，请问如何处理（假设连接器线程仍将使用每个连接的线程模型）会有什么不同吗？

请注意：关于tomcat 7的所有讨论。

Answer 1

acceptorThread（s）：这是一个或最多2个主题（如   文件中提到的，只负责接受   即将到来的连接。这可以使用配置   acceptorThreadCount，它建议可以使用两个以上   对于多CPU机器 -

为什么会这样？

接受连接是一项成本非常低的操作，因此将多个线程专用于此任务是没有意义的。

Does this imply that the number of simultaneous open connections 
scales with the number of cpus versus the number of open file descriptors 
allowed on the server system ?

不，它不是因为它在CPU方面成本非常低。对于文件描述符，每个接受的连接都将使用文件描述符，因此服务器可以接受的最大连接数受可用文件描述符数量的限制。

maxConnections（s）：

此设置与acceptCount和数字之间的关系是什么   在系统上打开文件描述符。

maxConnections不能高于系统上打开文件描述符的数量。请记住，其他进程也使用文件描述符，因此可能希望对可用文件描述符的maxConnections保守，让我们说maxConnections＆lt;文件描述符/ 2.

Why is the default value for this so much higher for the NIO connector 
( 10000 ) than for the BIO ( = maxThreads ) ?

这是因为在NIO中，单个处理所有IO，而在BIO中，服务器需要创建/使用单独的每个线程连接。

acceptCount ：当所有请求处理线程都忙时，这是请求的队列。

当请求被放入此队列时，是否也分配了一个文件描述符？

是的，接受连接请求是正确的，但服务器尚未准备好提供请求，因此连接被放入队列中。这样做是为了防止TCP /堆栈超时连接请求，从客户端的角度来看，这些请求可能看起来像服务器。换句话说，服务器说“我在这里，一旦有资源就会处理您的请求”。

或者仅在请求被主动处理时，它是否使用文件描述符？

不。

希望这会有所帮助。

此致

Slava Imeshev

Tomcat连接器体系结构，线程池和异步servlet

1 个答案: