在 Goetz 的“Java Concurrency in Practice”中，在第 101 页的脚注中，他写道“对于此类不 I/O 且不访问共享数据的计算问题，Ncpu 或 Ncpu+1 线程产生最佳吞吐量；更多线程没有帮助，实际上可能会降低性能......"
我的问题是，在执行文件写入、文件读取、文件删除等 I/O 操作时，是否有关于使用线程数来实现最大性能的准则？我知道这只是一个指导数字，因为磁盘速度和许多其他因素都会影响到这一点。
不过，我想知道：20 个线程将 1000 个单独的文件写入磁盘的速度是否比 4 个 CPU 机器上的 4 个线程更快？
【问题讨论】：
标签： java multithreading io
实际上，I/O 密集型应用程序仍然可以从多线程中获益良多，因为并行读取或写入几个文件比顺序读取或写入文件要快得多。在整体吞吐量受到网络延迟影响的情况下尤其如此。但也有这样的情况，一个线程可以在另一个线程忙于读取时处理它读取的最后一个内容，从而允许更高的 CPU 利用率。
我们可以整天谈论理论，但正确的答案是使线程数可配置。我想你会发现将它增加到超过 1 会提高你的速度，但也会出现收益递减点。
【讨论】：
是的，在 4 CPU 机器上，20 个线程绝对可以比 4 个线程更快地写入磁盘。许多实际程序的 I/O 限制比 CPU 限制更多。但是，这在很大程度上取决于您的磁盘以及其他线程在最终等待这些磁盘之前正在执行多少 CPU 工作。
如果您的所有线程都只写入磁盘而不做任何其他事情，那么很可能 4 CPU 机器上的 1 个线程实际上是写入磁盘的最快方式。这完全取决于您拥有多少磁盘、您正在写入多少数据以及您的操作系统在 I/O 调度方面的表现如何。您的具体问题表明您希望 4 个线程都写入同一个文件。这没有多大意义，在任何实际情况下，我都无法想象这会更快。 （你必须提前分配文件，然后每个线程会 seek() 到不同的位置，最后你会在每个线程试图写一些块时敲打写头。）
当您受网络限制时，多线程的优势要简单得多。即：在数据库服务器或网络浏览器等上等待。您正在等待多个外部资源。
【讨论】：
如果您使用的是同步 I/O，那么您的机器可以处理的每个同步 I/O 请求都应该有一个线程。如果是单轴单硬盘，则为 1（您可以读取或写入，但不能同时读取）。对于可以同时处理多个 I/O 请求的磁盘，它可以同时处理多个请求。
换句话说，这不受 CPU 计数的限制，因为除了提交请求和等待之外，I/O 并没有真正达到 CPU。 See here for a better explanation.
还有一大堆蠕虫，你应该在任何给定时间处理多少 I/O 请求。
【讨论】：
另见Will using multiple threads with a RandomAccessFile help performance?
更新： 我在那里添加了一个基准。
【讨论】：
就像所有与性能相关的事情一样。
如果您受 I/O 限制，那么添加线程对您毫无帮助。 （好的，正如Steven Sudit 指出的那样，您可能会提高性能，但会很小） 如果您不受 I/O 限制，那么添加线程可能会有所帮助
不要试图变得聪明，但最好的发现方法是分析它，看看什么适合你的特定情况。
编辑：基于 cmets 更新
【讨论】：
Ncpu + 预期的并发 IO 活动数是我通常的数字。
关键不是 20 个线程可以比 4 个线程更快地将单个文件写入磁盘。如果每个 cpu 只有 1 个线程，那么当您写入磁盘时，您的进程将无法使用托管正在执行文件 IO 的线程的 cpu。该 CPU 正在有效地等待文件被写入，而如果您还有一个线程，它可以在此期间使用 CPU 进行实际处理。
【讨论】：
如果您对该线程执行的唯一操作是写入磁盘，那么您的性能提升将微不足道，甚至有害，因为驱动程序通常针对硬盘驱动器的顺序读取进行了优化，因此您正在转换文件中的顺序写入到几个“随机”写入。
如果在性能方面对不同的磁盘、不同的网卡或不同的数据库服务器执行 I/O，多线程只能帮助您解决 I/O 绑定问题。尽管如此，就观察到的性能而言，差异可能更大。
例如，假设您通过网络将多个文件发送到许多不同的接收者。您仍然受网络限制，因此您的最大速度不会高于 100Mb/S，但是，如果您使用 20 个线程，那么该过程将更加公平。
【讨论】：