我想了解Tomcat的BIO和NIO连接器的线程模型 . 我正在引用官方Tomcat 7文档中的连接器，可以找到here . 基于此，这是我所怀疑的：
-
acceptorThread(s) ：这是单个或最多2个线程（如文档中所述），它仅负责接受进入的连接 . 这可以使用acceptorThreadCount进行配置，并建议多个机器可以使用两个以上 -
-
这是为什么？
-
这是否意味着同时打开的连接数量与服务器系统上允许的cpus数量与打开文件描述符数量成比例？
-
maxConnections(s) ：
-
此设置与acceptCount之间的关系是什么，以及系统上打开的文件描述符的数量 .
-
为什么NIO连接器（10000）的默认值比BIO（= maxThreads）高得多？
-
acceptCount ：当所有请求处理线程都忙时，这是请求的队列 .
-
当请求被放入此队列时，是否也为其分配了文件描述符？或者仅当请求被主动处理时，它是否使用文件描述符？
-
request processing threads ：此池中的线程数由maxThreads和minSpareThreads属性配置 .
-
此线程池与acceptorThreads之间的关系是什么？接受者线程是否会产生此池中的线程？
-
据我所知，NIO模型对请求处理线程的效率高于BIO模型 . 它如何实现这种效率？
-
正如我在各种来源中所读到的，NIO模型中的线程遵循每个请求范例的线程与BIO模型的每个连接范例的线程 . 此外，在NIO连接器模型中，实际请求处理被委托给不同的应用程序监视线程，而服务器的请求处理线程返回到线程池，以接受更多连接 . So, does this imply that the benefit of the NIO model will only be apparent if the connections to the server are of the HTTP Keep-Alive nature or if the application is using Servlet 3.0's asynchronous processing feature ?
-
Servlet 3.0 ：
-
使用Servlet 3.0时，应用程序servlet线程池的大小（相对于连接器线程池大小）应该达到最佳效率？
-
当使用BIO模型和它们时，将如何处理请求（假设连接器线程仍然使用每个连接模型的线程）会有什么不同吗？
请注意：关于tomcat的所有讨论7 .
1 回答
接受连接是一种成本非常低的操作，因此将多个线程专用于此任务是没有意义的 .
不，它不是因为它在CPU方面是一个非常低成本的操作 . 对于文件描述符，每个接受的连接将使用文件描述符，因此服务器可以接受的最大连接数受限于可用文件描述符的数量 .
maxConnections不能高于系统上打开文件描述符的数量 . 请记住，其他进程也使用文件描述符，因此可能希望对可用文件描述符使用maxConnections保守，假设maxConnections <文件描述符/ 2 .
这是因为在NIO中，单个处理所有IO，而在BIO中，服务器需要创建/使用单独的每个线程连接 .
是的，接受连接请求是正确的，但服务器尚未准备好提供请求，因此连接被放入队列中 . 这是完成以防止TCP /堆栈超时连接请求，从客户端的角度看，它可能看起来像服务器 . 换句话说，服务器说'我在这里，一旦我有资源就会处理你的请求' .
不 .
希望这可以帮助 .
问候，
Slava Imeshev