我有一个 tomcat6 servlet 应用程序。我的一个请求（平均约 10 秒）可以通过使用多线程得到显着改善，因为它是一个仅限 CPU 的任务并且我有 >= 8 个内核。我只是想知道这样做是聪明还是只是表面上的改变：
当然，对于单一用户案例，这是一种改进。但是如果负载增加会发生什么？我有一个有限的 CPU 能力，目前在几个 HTTP 连接器线程之间共享。假设我已经对它们进行了最佳配置，我将不得不从 http 连接器线程池中获取一些线程并将其放入某个执行器服务器中，以加快这个单一（但重要的）操作。
我的假设是，随着负载的增加，如果我使用额外的线程执行器服务，我的系统性能会更差。
你看到我的问题了吗？有没有人有一些最佳实践的想法？还是我忽略了什么？
在性能问题的情况下，除了少数例外，最好的答案通常是制定一个基准测试并尝试一下。
请记住，某些任务无法并行化。也就是说，尝试这样做要么需要同步，这样不会获得任何好处，要么根本不可能，因为每个步骤都需要完成前一个步骤。如果您的任务不能并行化，那么将没有任何好处。
同样，并非所有应用程序的活动都必须并行运行。在某种程度上，您的应用程序的某些部分会在文件系统或网络的 I/O 方面相互阻塞，甚至可能在您的数据库中等待请求的范围内。所有这些都意味着仅仅因为您的硬件可能只有 8 个核心（例如）并不意味着您应该严格限制自己使用 8 个或 9 个线程。当然，您也不想发疯并拥有数百个。
据我了解这个问题，如果您有 1 个并发请求并且您将工作（大约需要 10 秒）分成几个较小的工作单元，这些工作单元可以并行化并稍后加入，您希望创建一些额外的线程，这将受益。
而且您担心这实际上会降低性能，例如，如果您有 100 个并发请求，因为您没有备用内核来并行化这 100 个作业中的每一个。
理论上最小的开销是当活动线程的数量等于物理内核的数量时。所以你需要问自己一个问题——你最常见的情况是什么（系统有多少用户？），如果用户数量达到峰值，你准备支付什么价格。
无论如何，我完全同意蒂姆的观点，你应该进行基准测试，从理论上判断这几乎是不可能的。例如，如果您的 10 秒任务是 100% CPU-bound VS 80% CPU-bound，那么您的结果可能会完全不同。衡量，不要猜测。