【Go并发调度艺术】02 可伸缩的并发引擎：从分布式调度到M:P:N模型的演进

请点击上方蓝字TonyBai订阅公众号！

你好，我是Tony Bai。

欢迎回到【Go并发调度艺术】微专栏。在上一篇中，我们探讨了Go并发设计的初心，goroutine的轻量化本质，以及早期M:N调度模型是如何尝试满足这些目标的。我们也看到了，尽管早期模型解决了一些核心问题，但其依赖的全局运行队列 (GRQ) 和全局锁，在高并发场景下成为了一个致命的伸缩性瓶颈 (Not Scalable!)。

今天，我们将继续跟随Dmitry Vyukov的设计思路，看看Go调度器是如何一步步破解这个全局锁魔咒，通过引入分布式调度思想、工作窃取机制，并最终演化出我们今天熟知的、高度可伸缩的M:P:N（GMP）模型的。

破解全局锁的魔咒：走向“分布式”

面对全局锁的瓶颈，一个自然的想法是：“能不能用无锁（lock-free）数据结构替代？” Dmitry也曾探讨过这个问题。然而，他指出，无锁并非万能药。虽然无锁算法避免了操作系统层面的互斥锁，但其底层的原子操作在多核环境下仍然存在对共享内存的竞争（比如缓存行争用），有时甚至可能因为过度复杂的同步逻辑而导致性能还不如细粒度的锁。