每个连接线程与每个请求线程之间的区别是什么？

以上两种策略中的哪一种可以更好地扩展，为什么？

每个请求线程的可伸缩性比每个连接线程的可伸缩性更好。

Java线程非常昂贵，通常每个线程都使用1Mb的内存段，无论它们是活动的还是空闲的。如果为每个连接提供自己的线程，则该线程通常在连接的连续请求之间处于空闲状态。最终，框架需要停止接受新的连接（因为它无法创建更多线程），或者开始断开旧的连接（如果/当用户醒来时会导致连接中断）。

尽管由于TCP / IP的工作方式，每个IP地址有64K个开放连接的限制，但HTTP连接所需的资源比线程堆栈少得多。

相反，在每个请求线程模型中，仅在处理请求时才将线程关联。这通常意味着服务需要更少的线程来处理相同数量的用户。而且由于线程使用大量资源，这意味着该服务将具有更大的可伸缩性。

（并且请注意，每个请求线程数并不意味着框架必须关闭HTTP请求之间的TCP连接…）

话虽这么说，当每个请求的处理过程中出现长时间的停顿时，每个请求线程模型并不理想。（并且，当服务使用彗星方法时，这涉及长时间保持答复流处于打开状态，这是不理想的。）为此，Servlet
3.0规范提供了一种“异步Servlet”机制，该机制允许Servlet的request方法执行以下 *** 作：暂停其与当前请求线程的关联。这将释放线程去处理另一个请求。

如果可以将Web应用程序设计为使用“异步”机制，则它可能比每个请求线程或每个连接线程更具可伸缩性。

跟进

假设一个网页包含1000张图片。这导致1001个HTTP请求。进一步假设使用HTTP持久连接。使用TPR策略，这将导致1001线程池管理 *** 作（TPMO）。使用TPC策略，这将产生1个TPMO
…现在，根据单个TPMO的实际成本，我可以想象出TPC可能比TPR更好地扩展的情况。

我认为有些事情您尚未考虑：

• Web浏览器面临许多URL，需要提取这些URL才能完成页面，因此很可能会打开多个连接。

• 使用TPC和持久连接，线程必须等待客户端接收响应并发送下一个请求。如果网络等待时间较长，则此等待时间可能很长。

• 服务器无法知道何时可以关闭给定的（持久）连接。如果浏览器没有关闭它，它可能会“徘徊”，绑住TPC线程，直到服务器超时连接为止。

• TPMO开销不是很大，尤其是当您将池开销与上下文切换开销分开时。（您需要这样做，因为TPC会在持久连接上引发上下文切换；请参见上文。）

我的感觉是，这些因素可能比为每个连接分配一个线程而节省的TPMO多。