为什么像这样涉及 I/O 或访问共享数据的计算问题需要比 Ncpu 线程更多的线程才能产生最佳吞吐量?

Why computational problems like this that do with I/O or access shared data need more than Ncpu threads yield optimal throughput?

Java 并发实践:

For computational problems like this that do no I/O and access no shared data, Ncpu or Ncpu+ 1 threads yield optimal throughput; more threads do not help, and may in fact degrade performance as the threads compete for CPU and memory resources.

为什么像这样涉及 I/O 或访问共享数据的计算问题需要比 Ncpu 线程更多的线程才能产生最佳吞吐量?

我的理解:

I/O operation will be blocked.Shared data will be synchronized by locking,other threads also will be blocked wait for shared data lock.If just Ncpu threads,threads will be blocked,cpu will remains idle, which lead to cpu unused.

我的理解正确吗?

Why computational problems like this that do with I/O or access shared data need more than Ncpu threads yield optimal throughput?

他们不一定1需要更多线程。

引用的意思是,具有显着 I/O 或显着锁争用的问题可能2 受益 来自更多线程比 CPUs。添加更多线程可能会增加 吞吐量 。如果线程阻塞在 I/O 或锁上,调度程序将尝试将 CPU 重新分配给另一个线程。因此,如果线程数超过 CPUs,则 更有可能 会有一个线程等待 运行。


1 - 例如,如果没有任何实际工作要做,添加线程没有区别。此外,您可能不希望应用程序使用所有可用资源。可能需要在比单个 Java 应用程序更大的范围内考虑“最佳吞吐量”。
2 - 我们不能说它 受益。例如,如果系统已经 I/O 饱和,那么添加一个只会产生更多 I/O 流量的额外线程将无济于事。类似的论点可能适用于锁争用。