我是springwebflux的学习者，并且阅读了以下系列文章（first，second，third）
在第三条中，我面对以下文字：
请记住，相同的应用程序代码可在Tomcat，Jetty或Netty上运行。 当前，Tomcat和Jetty支持在Servlet之上提供 3.1异步处理，因此每个线程最多只能请求一个请求。在Netty服务器平台上运行相同的代码时， 约束解除，服务器可以调度请求 同情网络客户端。只要客户不 阻止，每个人都很高兴。 Netty服务器的性能指标和 客户端可能显示相似的特征，但是Netty服务器是 不限于每个线程处理一个请求，因此 不使用大线程池，我们可能希望看到一些 资源利用的差异。我们稍后会再说 在本系列的另一篇文章中。
首先，我看不到该系列的新文章，尽管该文章写于2016年。对我来说，很明显，tomcat默认具有100个线程来处理请求，一个线程同时处理一个请求，但是我不明白短语每个线程只能有一个请求是什么意思？
我还想知道Netty在该具体情况下如何工作（我想了解与Tomcat的区别）。每个线程可以处理2个请求吗？
答案 0 :(得分：3)
使用Servlet 2.5时，Servlet容器会将请求分配给线程，直到该请求被完全处理为止。
使用Servlet 3.0异步处理时，服务器可以在应用程序处理请求时在单独的线程池中分派请求处理。但是，当涉及到I / O时，工作总是在服务器线程上进行，并且总是阻塞。这意味着“慢速客户端”可以垄断服务器线程，因为服务器在网络连接不良的情况下对该客户端进行读/写操作时服务器被阻止。
在Servlet 3.1中，允许异步I / O，在这种情况下，不再使用“一个请求/线程”模型。任何时候都可以在服务器管理的不同线程上安排位请求处理。
Servlet 3.1+容器通过Servlet API提供了所有这些可能性。应用程序可以利用异步处理或非阻塞I / O。在非阻塞I / O的情况下，范式更改非常重要，使用起来确实具有挑战性。
使用Spring WebFlux-Tomcat，Jetty和Netty并不具有完全相同的运行时模型，但是它们都支持反应性背压和非阻塞I / O。
答案 1 :(得分：1)
当前有2个基本概念来处理对Web服务器的并行访问，具有各种优点和缺点：
阻塞式多线程服务器的第一个概念在池中具有有限数量的线程。每个请求都将分配给特定的线程，并且该线程将一直分配给请求，直到该请求已被完全满足。这基本上与超级市场中结帐队列的工作原理相同，一次有一条平行线的顾客。在大多数情况下，Web服务器中的请求在处理请求的大部分时间中都是cpu-idle。这是因为它必须等待I / O：读取套接字，写入db（基本上也是IO），然后读取结果并写入套接字。另外，使用/创建一堆线程很慢（上下文切换），并且需要大量内存。因此，此概念通常不使用它非常有效的硬件资源，并且对可以并行服务多少个客户端有严格的限制。此属性被滥用在所谓的饥饿攻击中，例如slow loris，通常只有一个客户端可以毫不费力地DOS大型多线程Web服务器的攻击。</ p>
大多数“常规” Web服务器都以这种方式工作，例如较旧的tomcat，Apache Web服务器以及所有Servlet早于3或3.1等的版本。
相比之下，非阻塞Web服务器只能通过一个线程为多个客户端提供服务。那是因为它使用了 non-blocking kernel I/O features 。这些只是内核调用，当可以写入或读取某些内容时，它们会立即返回并回调，从而使CPU可以自由地执行其他工作。重用我们的超市比喻，这就像当收银员需要其主管解决问题时，他不等待并阻塞整个通道，而是开始检查下一个客户，直到主管到达并解决第一个客户的问题为止。客户。
这通常是在事件循环或更高层次的green-threads或fibers中完成的。从本质上讲，这样的服务器不能真正地同时进行任何处理（当然，您可以有多个非阻塞线程），但是它们能够并行服务数千个客户端，因为内存消耗不会随着与多线程概念完全一样（阅读：最大并行客户端没有硬性限制）。也没有线程上下文切换。不利的一面是，非阻塞代码通常读写起来更复杂（例如callback-hell），并且在请求执行大量CPU昂贵工作的情况下，这种情况并非一帆风顺。
大多数现代的“快速” Web服务器和框架促进了非阻塞性概念：Netty，Vert.x，Webflux，nginx，Servlet 3.1 +，Node，Go Web服务器。
作为旁注，在此基准页面上，您会看到大多数最快的Web服务器通常都是非阻塞服务器：https://www.techempower.com/benchmarks/