问每个连接的线程和每个请求的线程有什么不同？

EN

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

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

Java线程是相当昂贵的，通常每个线程使用1Mb的内存段，无论它们是活动的还是空闲的。如果您为每个连接提供自己的线程，则该线程通常会在对该连接的连续请求之间处于空闲状态。最终，框架需要要么停止接受新连接(因为它不能创建更多线程)，要么开始断开旧连接(这会在用户醒来时导致连接混乱)。

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

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

(请注意，每请求一个线程并不意味着框架必须关闭HTTP请求之间的TCP连接...)

话虽如此，当每个请求的处理过程中存在长时间停顿时，每个请求的线程模型并不理想。(当服务使用comet方法时，这尤其不理想，这种方法需要长时间保持应答流的打开。)为了支持这一点，Servlet 3.0规范提供了一种“异步servlet”机制，该机制允许servlet的请求方法暂停其与当前请求线程的关联。这会释放线程去处理另一个请求。

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

后续

让我们假设一个包含1000张图片的网页。这将导致1001个HTTP请求。此外，让我们假设使用了HTTP持久连接。使用TPR策略，这将导致1001个线程池管理操作(TPMO)。使用TPC策略，这将导致1个TPMO...现在，根据单个TPMO的实际成本，我可以想象TPC可能比TPR扩展得更好的场景。

我认为有一些事情你没有考虑到：

web浏览器面对大量的URL来完成一个页面可能会打开多个connections.

• With
• 和持久连接，线程必须等待客户端接收响应并发送下一个请求。如果网络延迟很高，则此等待时间可能会很长。
• 服务器无法知道给定的(持久)连接何时可以关闭。如果浏览器不关闭它，它可能会“逗留”，直到服务器超时为止。connection.
• The TPMO开销不是很大，特别是当您将池开销与上下文切换开销分开时。(您需要这样做，因为TPC将在持久连接上引起上下文切换；请参见上文。)

我的感觉是，这些因素可能会超过TPMO为每个连接指定一个线程所节省的成本。

HTTP 1.1 -支持persistent connections，这意味着可以使用相同的HTTP连接接收/发送多个请求/响应。因此，为了并行运行使用相同连接接收的那些请求，需要为每个请求创建一个新的Thread。

HTTP 1.0 -在此版本中，只收到一个使用连接的请求，并且在发送响应后关闭连接。因此，只为一个连接创建了一个线程。

Thread per connection是重用来自multiple requests(keep-alive)的相同HTTP Connection的概念。

Thread per request将为each request创建一个线程，从一个client.Server可以创建多个threads作为每个request。