关于多线程下载的缺点

我有一个关于多线程下载的问题，正如您所知，使用多个线程下载可以提高应用程序的性能，但是有一些措施需要尊重：例如线程数、可用带宽等等，但我不太明白，为什么例如，使用多个线程可能会降低应用程序的性能，或者服务器的带宽、质量如何影响多线程应用程序的性能？ ，什么情况下单线程下载比多线程下载快？
感谢您的回复。

我假设您指的是下载管理器。

首先，我对下载管理器真正提供的“性能”优势持怀疑态度。但更重要的是，它们确实提供的任何好处是not由于多线程。下载的性能限制是带宽连接的。这就是为什么我对这些好处持怀疑态度：

• 1 Mbps 连接将以 1 Mbps 的速度下载。
• 将文件分成 4 个段意味着您以 256 Kbps 的速度下载每个段，并且 4 * 256 Kbps = 1 Mbps。
• 如果服务器限制每个下载段，您可能会得到一些改进。
• 如果其中一个片段超时，您可能会得到一点好处：其他片段正在下载，这意味着您的连接在超时等待期间不会闲置。
• 您还可以通过“淹没”任何其他尝试使用该连接的内容来加快下载速度。 （不过我并不是真的认为这是一种好处。）

下载管理器的真正好处是有效地自动重新启动下载（即，如果可能的话，不从头开始重新启动）。

那么多线程的意义何在呢？

首先我们要破除一个误区：多线程does not加快任何事情的速度。如果一个例程需要 X 个时钟周期来运行：它将需要 X 个时钟周期；无论是在 1 个线程还是多个线程上。

多线程的作用：它允许任务运行同时（同时）。

同时做不同事情的能力意味着：

• 慢速任务（组合大型下载的各个部分）可以在不同的线程上完成，而不会干扰需要快速反应的其他线程（例如用户界面）。
• 并发任务还可以更有效地使用更多可用资源（多个CPU）。请注意（回答问题的最后一部分）如果您只有一个 CPU，那么您的线程会被操作系统“时间切片”，因此它不是真正的并发。但时间片很小，所以之前的好处仍然适用。

什么时候单线程比多线程快？

嗯，几乎总是在 CPU 不是瓶颈的情况下。在下载的情况下：如前所述，瓶颈是连接两个端点之间的带宽。许多线程实际上意味着您必须做更多的工作（管理和协调不同的线程）。

最有效的下载方法是 2 个线程：一个用于 UI，另一个用于下载，这样任何暂停/延迟都不会阻塞用户界面。

然而，更一般地说，即使您的 CPU 密集型工作理论上可以从同时执行不同工作的多个线程中受益，但在实现过程中也很容易犯错误：实际上会减慢你的应用程序速度.

• 理想情况下，您的多个任务不应共享数据。因为如果他们这样做，那么你就有风险竞争条件 or 并发性 bugs.
• 当他们确实必须共享数据时，您需要以某种方式同步工作以避免上述错误。 （有很多技术可以根据自己的需要进行选择，这里不再赘述。）
• However if your synchronisation is poorly planned you risk introducing a number of problems that can significantly slow down your application. These include:
  • 通过共享资源造成瓶颈，使您的多个线程在任何情况下都无法同时运行。
  • 高锁争用，任务花费更多时间等待而不是工作。
  • 甚至死锁也会完全阻止某些任务。