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

在IT行业这个发展更新速度很快的行业，只有不停止的学习，才不会被行业所淘汰。如果你是Golang学习者，那么本文《Go 会阻塞像 Node 这样的处理器密集型操作吗？》就很适合你！本篇内容主要包括Go 会阻塞像 Node 这样的处理器密集型操作吗？，希望对大家的知识积累有所帮助，助力实战开发！

问题内容

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

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

Node.js 的缺点是它无法处理处理器密集型操作（例如 for 循环），并且正在运行的虚拟进程将一直持续到完成而没有抢占，这就是为什么 Node.js 被认为是明智的在用于关键系统之前，尽管它具有高并发可用性。

是的，Go 生成了一个新线程来处理阻塞的 go-routine，但是处理器密集型操作怎么样，它们被认为是相同的，还是遭受 Node 问题的困扰？

正确答案

是的，但它在实践中比使用 Node 更难遇到，而且更容易从中恢复。Node 是单线程的，除非您显式地编写多进程代码（这并不总是那么容易，尤其是在您想要可移植的情况下）。Go 使用具有一定最大运行线程数的 N:M 调度（默认情况下等于逻辑 CPU 的数量，但可调整）。注意 running ：等待阻塞操作的 goroutine 被“冻结”并且不算占用正在运行的线程。

所以，如果你有一个 goroutine 做一些 CPU 密集型的事情，它通常不会影响其他 goroutine 的运行能力，因为有很多其他线程可以运行它们。如果你 所有 的 goroutine 都忙于计算，那么在一个放弃 CPU 之前，其他 goroutine 确实没有机会运行。如果他们实际上正在完成工作，这可能 不一定是问题，因为您所有的 CPU 都在做实际工作，但当然有时它可能处于延迟敏感的情况。

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

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

2. 使用工作池将并行 CPU 密集型工作的数量限制在 GOMAXPROCS 以下。Go 让这很容易。

3. 硬币的另一面：将 GOMAXPROCS 提高到预期的并行计算任务数量之上。这可能是最糟糕的想法，并且至少会在某种程度上损害调度，但它仍然可以工作，并确保您有可用于处理事件的线程。

今天关于《Go 会阻塞像 Node 这样的处理器密集型操作吗？》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！