所以，我几天前开始使用Minecraft并打开它的开发者控制台，看看它在更新时的作用。我注意到其中一条线说了以下内容：
Downloading 32 files. (16 threads)
现在，首先想到的是：处理器一次只能做一件事，所有线程都会将每个任务分开并在它们之间分配CPU功率，那么目的是什么呢？如果每个线程仍然只在一个处理器上运行，那么在多个线程上下载多个文件？
然后，在决定是否应该在SO上提出这个问题的过程中，我记得多个核心可以驻留在一个处理器上。例如，我的处理器是四核的。因此，您实际上可以真正同时完成4次下载。现在听起来很有道理。除了有16个线程用于我的世界的下载。所以，基本上我的问题是：
在下载过程中增加线程数是否有助于提高速度？ （假设有一个多核处理器，并且线程数小于核心数。）
和
如果增加线程数超过内核数量，速度是否还会增加？ （对我而言，在四核处理器上，4个线程之后的下载量将达到最大速度。）
答案 0 :(得分：5)
下载是网络绑定的，不受CPU限制。因此从理论上讲，使用多个线程不会使它更快。
一方面，如果您的程序使用同步（阻塞）I / O进行下载，那么多个线程只会减少阻塞。通常，另一方面，使用具有异步I / O的单个线程更为明智。
在握手方面，异步I / O比同步I / O更加难以编码（这很简单）。因此开发人员可能刚刚决定优先考虑简单的编程而不是纯粹的性能。 （或者他们可能赞成与旧Java平台的兼容性：真正的异步I / O仅适用于NIO2（Java 7附带）。）
答案 1 :(得分：1)
通常它不会更快，但总有例外。
假设每个下载线程，您正在打开一个新连接，然后是
或者，如果“下载”不是普通下载，而是下载内容并对其进行一些CPU密集处理。
在这种情况下，当有多个线程时，您可能会看到下载速度变快。
答案 2 :(得分：0)
当一个线程下载一个文件时，它会花一些时间等待。当一个线程一个接一个地下载N个文件时，它将平均花费N倍的总等待时间。
当每个N个线程下载一个文件时，每个线程都会花一些时间等待，但其中一些等待将重叠（例如，线程A和线程B都在同时等待。）最终结果是可能花费更少的挂钟时间来获取所有N个文件。
另一方面，如果线程正在等待来自同一服务器的文件，则每个线程的单独等待时间可能会更长。
是否存在整体性能优势的问题取决于客户端，服务器以及可用网络带宽。如果网络不能像服务器一样快地携带字节，那么多线程客户端可能不会节省任何时间，如果服务器是单线程的，那么多线程客户端肯定不会帮助，但如果条件是正确的（例如，如果你有一个快速的互联网连接，特别是如果文件来自服务器 farm 而不是一台机器），那么多线程可能会加速事情发生了。