如果当前内核正在调度 60 个线程，它们属于 3 个进程：
A：10 个线程
B：20 个线程
C：30 个线程
而且他们都在做计算（没有磁盘 IO）
C 会比 B 完成更多的工作，而 B 会比 A 完成更多的工作吗？
这对我来说似乎不太公平。如果我是一个不负责任的程序员，我可以产生更多的线程来消耗更多的 CPU 资源。
这与 golang 的关系： 在 go 中，通常 go 调度程序具有 #of-CPU-cores 线程的线程池。如果具有更多线程的进程完成更多工作，为什么这有意义？
【问题讨论】：
标签： multithreading go linux-kernel threadpool
您描述的情况是一台过载的机器。只有当 CPU 没有空闲时间时，线程多的进程才能完成更多的工作。
Go 并非旨在与其他进程争夺更大份额的过载 CPU。如果您想参加这样的战斗，您可以随意将GOMAXPROCS 设置为您喜欢的任何数字。
在一个更典型的系统中，总工作量小于总 CPU 时间；一个有 8 个线程和 30 个 goroutine 的 Go 进程的性能与一个同时运行 30 个线程的进程的性能大致相同。
【讨论】：
这对我来说似乎不太公平。如果我是一个不负责任的程序员， 我可以产生更多的线程来消耗更多的 CPU 资源。
您还可以分配整个空闲内存，导致操作系统故障并劫持网卡。你可以做各种各样的事情，但谁会想要使用你的软件？
这与 golang 的关系：在 go 中，go 调度程序通常有一个 #of-CPU-cores 线程的线程池。为什么这有意义，如果 拥有更多线程的进程可以完成更多工作？
Golang goroutines 基本上是一个线程池。每个 goroutine 都是一个线程池工作项。许多事情可以使您的线程池线程阻塞，例如使用同步 IO、等待（非自旋锁）锁以及手动休眠或屈服。在这些非常常见的情况下，拥有比 CPU 更多的线程通常会提高应用程序的性能。
请注意，并非所有 IO 都是磁盘 IO。写入控制台是 IO 操作，但它并不是真正的“磁盘 IO”。
另一件事是上下文切换可能不会消耗大部分 CPU，并且拥有更多线程可能不会使您的任务吞吐量下降。所以在这种情况下，拥有更多线程意味着您的并行度更高，但不会降低性能。这是有些常见的情况。如今，线程之间的上下文切换非常便宜。拥有比内核多一点的线程可能不需要以某种方式降低性能或降低性能。
【讨论】：
having more threads than CPU's usually increase the performance of your application 评论：我同意拥有比 CPU 内核更多的线程更好，但你不需要为此增加 GOMAXPROXCS ：“在 I/O 或其他系统调用中阻塞的 Goroutine 或正在调用非 GO 函数，确实需要一个 OS 线程，但 GOMAXPROXCS 不需要考虑它们”来自 GOMAXPROXCS 设置为内核数对我来说没有意义 --- 使用内核数作为线程池中的线程数将毫无意义。