多线程下载真的会加快速度吗？

Question

所以，我几天前启动了我的世界，并打开了它的开发者控制台，看看它在自我更新时做了什么。我注意到其中一行是这样说的：

Downloading 32 files. (16 threads)

现在，首先想到的是：处理器一次仍然只能做一件事，所有线程所做的只是将它们的每个任务分开并在它们之间分配 CPU 功率，那么目的是什么如果每个线程仍然只在单个处理器上运行，则在多个线程上下载多个文件？

然后，在决定是否应该在 SO 上提出这个问题的过程中，我记得多个内核可以驻留在一个处理器上。例如，我的处理器是四核的。因此，您实际上可以真正同时完成 4 次下载。现在这听起来很有意义。除了有 16 个线程用于下载 minecraft 之外。所以，基本上我的问题是：

在下载过程中增加线程数对速度有帮助吗？ （假设是多核处理器，并且线程数小于核心数。）

和

如果将线程数增加到超过内核数，速度还会提高吗？ （在我看来，在四核处理器上，4 个线程后的下载速度将达到最大。）

Answer 1

下载是网络绑定的，而不是 CPU 绑定的。所以理论上，使用多线程并不会让它更快。

一方面，如果您的程序使用同步（阻塞）I/O 进行下载，那么多线程只会减少阻塞的发生。另一方面，一般来说，只使用具有异步 I/O 的单线程更为明智。

从表面上看，异步 I/O 比同步 I/O 更难正确编码（这很简单）。因此，开发人员可能刚刚决定更倾向于易于编程而不是纯粹的性能。 （或者他们可能倾向于与旧的 Java 平台兼容：真正的异步 I/O 仅适用于 NIO2（Java 7 附带）。）

Answer 2

通常不会更快，但总会有例外。

假设对于每个下载线程，你都在打开一个新的连接，那么如果

1. 网络（您自己的网络或目标系统）限制了每个连接的下载速度，或者
2. 您正在从多个服务器等下载

或者，如果“下载”不是普通下载，而是下载某些内容并对其进行一些 CPU 密集型处理。

在这种情况下，您可能会看到多线程时下载速度会变快。

Answer 3

当一个线程下载一个文件时，它会花费一些时间等待。当一个线程一个接一个地下载 N 个文件时，它平均会花费 N 倍的总等待时间。

当 N 个线程每个下载一个文件时，这些线程中的每一个都会花费一些时间等待，但其中一些等待会重叠（例如，线程 A 和线程 B 都在同时等待。）最终结果是可能花更少的时间来获取所有 N 个文件。

另一方面，如果线程正在等待来自同一服务器的文件，则每个线程的单独等待时间可能会更长。

是否存在整体性能优势的问题取决于客户端、服务器以及可用的网络带宽。如果网络不能像服务器将字节抽出一样快，那么客户端多线程可能不会节省任何时间，如果服务器是单线程，那么客户端肯定不会多线程帮助，但如果条件合适（例如，如果您有快速的互联网连接，特别是如果文件来自服务器 farm 而不是单台机器），那么多线程可能会加快事情发生了。