如果同时有很多请求，多线程会提高性能吗？答案

【问题标题】：Does multi-threading improve performance if there are many requests at the same time?如果同时有很多请求，多线程会提高性能吗？
【发布时间】：2013-07-05 13:23:46
【问题描述】：

我正在使用托管在 Tomcat 7 上的 Spring 3 开发 Java Web 应用程序，该应用程序需要每秒处理超过 2.5k 个请求。我有一个RequestProcesseor 类，使用此方法处理每个 HTTP 请求：

@Service
public class RequestProcesseor {

    public void processSomething(int value1, int value2) {
        // process something...
        // create and deep copy some object
        // some BigDecimal calculations
        // maybe some webservice calls
    }

}

同时有超过2500个请求，会调用processSomething方法。如果我让这个类成为多线程的。 它会提高性能吗？如果是，为什么？我该如何证明呢？

服务器有一个 4 核 CPU。

【问题讨论】：

哇，使用弹簧的伟大足球运动员。
使用 servlet 3.0 异步支持：blog.springsource.org/2012/05/06/…
我认为 2.5k 请求/秒可能需要集群：tomcat.apache.org/tomcat-7.0-doc/cluster-howto.html

标签： java multithreading spring tomcat

【解决方案1】：

即使您没有显式地执行任何多线程，您的应用程序服务器也会隐式地将每个请求分派到自己的线程，因此您已经在 CPU 上承受了并发负载。

仅当您的请求处理受 CPU 限制时，并发代码才会对您有所帮助，这种情况很少见。通常瓶颈是数据库，或者更一般地说，是其他后端子系统的接口。

如果每个请求都是通过处理大量内存数据来处理的，并且如果每秒请求的负载很低，那么它可以得到回报小心地将工作分配给几个线程，不超过实际的 CPU 核心数。

因此，由于您的服务器负载非常重，几乎可以肯定通过将工作分派给多个线程来提高其性能是不可能的。请注意，多线程很容易破坏性能。

【讨论】：

【解决方案2】：

请注意，Tomcat 已经在做多线程了。

在应用服务器或 Web 容器中自行执行多线程并不总是明智的。

应用程序服务器或 Web 容器已经在对请求进行多线程处理。

请阅读 Tomcat 的文档和/或源代码。

【讨论】：

Web 容器对请求进行多线程处理，但每个请求都可能受益于进一步的多线程处理。
@BrianAgnew 没错，但据我所知，他假设给定的类是单线程的，不需要正确。这取决于应用程序服务器。也许单个请求可以更快地处理，但我们只能假设。

【解决方案3】：

它会提高性能吗？

也许吧。您每秒有 2.5k 个请求。如果每个请求都花费 1 秒的 CPU 时间，而您有一个 CPU，那么它不会。如果您有 2 个 CPU，那么可以。如果每个请求都与远程池化网络资源通信，那么可以。如果每个请求都与相同的网络资源通信（即未池化），则不会。

简而言之，您需要提供有关您正在做什么的更多信息，并且（最有用的是）使用您的特定环境自己执行测试。

【讨论】：

【解决方案4】：

简短回答：是的。

每次有请求进来，如果你只使用1个线程来执行这个方法，这意味着下一个请求要等到前一个请求被处理完。

如果您每次收到请求时都创建一个新线程，那么您将在系统上有可用资源时立即处理所有请求。无论如何，您的线程将在完成后被清理。

【讨论】：

在 2500 个并发请求时，会产生大量线程创建和销毁开销。并且取决于单个请求需要多长时间来处理比核心多得多的线程。我建议为此使用 ThreadPool。
@confusopoly 如果处理位真的很短，我同意这一点。但是他没有显示他的处理代码，所以我不知道:)
问题是关于使 这个类 多线程。请求处理已经是多线程的。

【解决方案5】：

简短的答案是：您必须自己衡量。

更长的答案是：如果您将工作分派到后台的单个线程，并且 HTTP 请求处理器等待该后台线程的完成（它还会做什么？）您刚刚增加了应用程序的开销

请

衡量是否有影响
如果您有积极影响：检查您衡量的影响并确定增加的复杂性是否值得以可维护性和性能来换取

或者，更一般地说：

编写具有优化可维护性的代码
对应用程序进行压力测试，直到它崩溃
如果它比您预期的更早中断：
- 识别瓶颈（内存、cpu、i/o 等）
- 解决您发现的问题 #1
- 继续第 2 步
恭喜。您的应用程序可以满足您期望的负载并且代码处于最佳可维护状态，可以满足其性能要求

【讨论】：