问为web应用程序实现会话特定线程池的缺陷

EN

当您查看当今最具有高度可伸缩性的web应用程序(或服务)时，问题在于确保没有足够的可用线程，而是确保整个系统能够处理服务端点所需的并发web连接。

并发请求/秒对一次安装的最大进步来自于非阻塞I/O --本质上，当一个新客户端连接时，以及当新字节到达时，操作系统具有允许应用程序的方法。只要系统完全支持非阻塞I/O，单个线程就可以处理数千个异步连接。

一个系统一次可以有太多的活动线程。当这种情况发生时，操作系统花费更多的时间在线程之间切换上下文，而不是在线程中执行工作。拥有一个具有有限线程数的全局线程池来使用异步平台处理异步I/O，将有助于提高每秒处理数千个请求的效率。最好让总线程数一个多个核心在您的机器上(跨越所有CPU)。

另一个非常常见的解决方案是简单地让更多的服务器承载您的应用程序或web服务。每个服务器都在自己的进程中，很多时候是在不同的硬件上。如果有一个合适的“无共享”体系结构，那么您可以在负载均衡器允许的范围内进行扩展。

要添加到Berin的答案:在应用程序中添加更多的线程，超过CPU数量(每个核心可以有多个CPU)，只会在应用程序性能不受CPU限制的情况下提高性能。大多数web应用程序都是IO绑定的，这使得在这个空间中添加线程成为一个可行的策略。

但是，也存在线程切换开销:在某个时候，添加更多的线程会降低性能。你可能会感到惊讶的是，只有这么少的线程才能达到这一点。继续超越这个点，你最终会使系统瘫痪。结果是，您需要限制线程的总数。最有可能的原因是，您看到这与功能的划分是基于对这些不同活动的观察需求。如果对用户进行分配，则很难优化线程分配。您需要限制主机支持的用户数量。这可能对您的应用程序更好，也可能不会。

如果您想提高利用率，最好的选择是非阻塞IO (NIO)，它允许一个线程在IO绑定的应用程序中处理多个用户请求。简而言之:它不再等待(阻塞) IO请求，而是继续执行任何可用的工作。它这样做并不会引起系统级线程切换的成本。其结果是，一个服务器可以支持的用户数量大大增加。