是的，但是在实践中要比使用Node困难得多，并且从中恢复也要容易得多。节点是单线程的，除非您编写显式的多进程代码（这并不总是那么容易，特别是如果您希望具有可移植性）。Go使用N：M调度，并且具有一定数量的正在运行的最大线程数（默认情况下等于逻辑CPU的数量，但是可调）。注意
running ：等待阻塞操作的goroutine被“冻结”，不算在占用正在运行的线程中。
因此，如果您有一个goroutine进行CPU密集型工作，那么通常不会影响其他goroutine的运行能力，因为还有很多其他线程可以运行它们。如果您
所有 的goroutine都被计算所占据，那么其他程序确实没有机会运行，直到有人放弃了CPU。如果您实际上正在完成工作，那么这可能 不一定
会成为问题，因为您的所有CPU都在进行实际工作，但是当然有时可能在对延迟敏感的情况下。
如果有问题，可以想到三种解决方案：
runtime.Gosched
在长时间计算期间使用，可以控制处理器，从而使其他goroutine可以运行。无需进行其他任何更改；这只是与合作调度程序一起工作的一种方式。Gosched
可能会立即返回，也可能稍后返回。使用工作池将并行的CPU密集型工作量限制为少于GOMAXPROCS。Go使这变得非常容易。
同一枚硬币的另一面：将GOMAXPROCS提升到并行计算任务的预期数量以上。这可能是最糟糕的主意，并且至少会在一定程度上影响调度，但是它仍然可以正常工作，并确保您有可用于处理事件的线程。
