python-3.x - Goroutines vs asyncio 任务 + CPU 绑定(bind)调用的线程池

Question

goroutine 是否大致等同于 python 的 asyncio 任务，具有一个附加功能，即任何 CPU 绑定(bind)任务都被路由到 ThreadPoolExecutor 而不是添加到事件循环中(当然，假设我们使用没有 GIL 的 python 解释器)？

我遗漏的这两种方法之间有什么实质性区别吗？当然，除了作为 Go 不可或缺的一部分的并发性所带来的效率和代码清晰度之外。

Answer 1

我想我知道部分答案。我试图按重要性顺序总结我对 asyncio 任务和 goroutines 之间差异的理解:

1) 与 asyncio 不同，人们很少需要担心他们的 goroutine 会阻塞太久。 OTOH，跨 goroutine 的内存共享类似于跨线程的内存共享，而不是 asyncio 任务，因为 goroutine 执行顺序保证要弱得多(即使硬件只有一个内核)。

asyncio 只会在显式 await、yield 和某些事件循环方法上切换上下文，而 Go 运行时可能会打开更微妙的触发器(例如某些函数调用)。所以 asyncio 是完美协作的，而 goroutines 只是大部分是协作的(并且路线图表明它们会随着时间的推移变得更不协作)。

一个非常紧凑的循环(例如数字计算)仍然会阻塞 Go 运行时(好吧，它运行的线程)。如果发生这种情况，它将比在 Python 中产生更小的影响 - 除非它发生在多线程中。

2) Goroutines 对并行计算有现成的支持，这需要在 asyncio 下使用更复杂的方法。

Go 运行时可以并行运行线程(如果有多个内核可用)，因此它有点类似于在无 GIL python 运行时的线程池中运行多个 asyncio 事件循环，具有前面的语言感知负载平衡器。

3) Go 运行时将在单独的线程中自动处理阻塞系统调用；这需要在 asyncio 下明确完成(例如，使用 run_in_executor)。

也就是说，就内存成本而言，goroutines 非常像 asyncio 任务而不是线程。