node.js - Go 会阻塞像 Node 这样的处理器密集型操作吗？

Question

Go 非常适合并发，任务作为 go-routines 传递，go-routines 在虚拟处理器中处理，每当一个 go-routine 遇到阻塞操作(数据库调用)时，go-routine 被移动到不同线程上的另一个虚拟处理器，大部分时间在另一个物理处理器上运行......现在，我们实现了并行性。

Node.js 有类似的技术(除了一切都发生在同一个线程上)，但是将所有等待的虚拟进程放在一个等待队列中，直到它们收到来自阻塞资源(DB、URL)的响应，然后它们被发送到进行处理。

Node.js 的缺点是它无法处理处理器密集型操作(for 循环就是一个例子)，并且正在运行的虚拟进程将一直占用直到完成而不会抢占，这就是 Node.js 的原因尽管它具有高并发可用性，但在用于关键系统之前被视为明智之举。

是的，Go 生成了一个新线程来处理阻塞的 go-routine，但是处理器密集型操作如何，它们被认为是一样的，还是会遇到 Node 问题？

Answer 1

是的，但在实践中遇到它比使用 Node 困难得多，而且更容易从中恢复。 Node 是单线程的，除非您显式编写多进程代码(这并不总是那么容易，特别是如果您想要可移植)。 Go 使用具有一定最大运行线程数的 N:M 调度(默认情况下等于逻辑 CPU 的数量，但可调)。注意正在运行:正在等待阻塞操作的 goroutine 被“卡住”并且不计入占用正在运行的线程。

因此，如果您有一个 goroutine 执行 CPU 密集型操作，它通常不会影响其他 goroutine 的运行能力，因为有许多其他线程可用于运行它们。如果您的所有 goroutines 都忙于计算，那么其他 goroutines 确实没有机会运行，直到一个 goroutines 放弃 CPU。如果他们确实在完成工作，这可能不一定是个问题，因为您的所有 CPU 都在做实际工作，但当然有时它可能是在对延迟敏感的情况下。

如果这是一个问题，我会想到三种解决方案:

1. 在长时间计算期间使用 runtime.Gosched 来控制处理器，让其他 goroutine 有机会运行。无需进行其他更改；这只是与协作调度程序一起工作的一种方式。 Gosched 可能立即返回，也可能稍后返回。

2. 使用工作池将并行 CPU 密集型工作的数量限制在 GOMAXPROCS 以内。 Go 让这一切变得非常简单。

3. 同一枚硬币的反面:将 GOMAXPROCS 提高到高于并行计算任务的预期数量。这可能是最糟糕的想法，至少会在一定程度上损害调度，但它仍然有效，并确保您有可用于处理事件的线程。