如果运行时间很短（2 毫秒），是否值得使用多个线程？答案

【问题标题】：If the running time is short ( 2 ms), would it be worth to use multiple threads?如果运行时间很短（2 毫秒），是否值得使用多个线程？
【发布时间】：2012-08-29 17:50:40
【问题描述】：

我写了一个 Java 程序。对于一个小的输入，在预热之后（前 50 次运行），它的运行时间变成大约 2 毫秒。

在这种情况下，如果我使用多线程版本，我们能得到什么好处吗？如果没有，隐藏并行执行好处的开销是什么？

【问题讨论】：

“视情况而定”这句话肯定适用于此。您的应用程序不能接受 2 毫秒吗？多线程可能的性能改进之间的权衡是否值得引入额外的复杂性？多线程并不是提高性能的保证方法。
您真的想将 2ms 的计算拆分为多个线程吗？开销将是巨大的。
'如果我使用多线程'用于什么？程序的本质是什么？

标签： java multithreading parallel-processing

【解决方案1】：

启动线程的开销很可能远远超过任何加速。在 Windows 上，您甚至无法可靠地测量如此快速程序的执行时间。

但是，当然，您必须问自己是否真的需要对运行时间为 2 毫秒的程序进行任何加速。

【讨论】：

'很可能启动线程的开销将远远超过任何加速'..除非线程已经存在，即。池化或专用的“应用程序生命周期”线程。
@Martin James：是的。我假设他的整个应用程序在 2 毫秒内运行。

【解决方案2】：

Id 取决于 2ms 是否太慢。它还取决于您是否要同时运行这些任务。为什么不使用 Executor 来运行您的任务，然后您可以根据需要添加线程。

【讨论】：

【解决方案3】：

嗯，2ms 至少是在多个线程上拆分的候选。不断地创建/运行/终止/加入线程是一个非启动 - 无望的设计。如果向一组专用线程发送工作信号或向池发出工作，这完全取决于完成的工作和数据组织。

如果有任何阻塞或 CPU 密集型工作可以在这 2 毫秒内有效地并行执行，那么您可以试一试。 CPU 密集型工作的关键问题是有多少数据以及如何组织数据。如果要处理的数据可以很容易地分割成不错的 [L1-cache-size 或更小] 块，那么您就是赢家。如果没有，请做好失望的准备。

你当然可以试试看..

【讨论】：