思考 GM 模型
通过对 Go1.0.1 的调度器源码剖析，我们可以发现一个比较有趣的点。那就是调度器本身（schedule 方法），在正常流程下，是不会返回的，也就是不会结束主流程。
他会不断地运行调度流程，GoroutineA 完成了，就开始寻找 GoroutineB，寻找到 B 了，就把已经完成的 A 的调度权交给 B，让 GoroutineB 开始被调度，也就是运行。
当然了，也有被正在阻塞（Blocked）的 G。假设 G 正在做一些系统、网络调用，那么就会导致 G 停滞。这时候 M（系统线程）就会被会重新放内核队列中，等待新的一轮唤醒。
GM 模型的缺点
这么表面的看起来，GM 模型似乎牢不可破，毫无缺陷。但为什么要改呢？
在 2012 年时 Dmitry Vyukov 发表了文章《Scalable Go Scheduler Design Doc》，目前也依然是各大研究 Go 调度器文章的主要对象，其在文章内讲述了整体的原因和考虑，下述内容将引用该文章。
当前（代指 Go1.0 的 GM 模型）的 Goroutine 调度器限制了用 Go 编写的并发程序的可扩展性，尤其是高吞吐量服务器和并行计算程序。
实现有如下的问题：
GMP 模型
为了解决 GM 模型的以上诸多问题，在 Go1.1 时，Dmitry Vyukov 在 GM 模型的基础上，新增了一个 P（Processor）组件。并且实现了 Work Stealing 算法来解决一些新产生的问题。
GMP 模型，在上一篇文章《Go 群友提问：Goroutine 数量控制在多少合适，会影响 GC 和调度？》中已经讲解过了。
觉得不错的小伙伴可以关注一下，这里就不再复述了。
带来什么改变
加了 P 之后会带来什么改变呢？我们再更显式的讲一下。
为什么要有 P
这时候就有小伙伴会疑惑了，如果是想实现本地队列、Work Stealing 算法，那为什么不直接在 M 上加呢，M 也照样可以实现类似的功能。
为什么又再加多一个 P 组件？
结合 M（系统线程） 的定位来看，若这么做，有以下问题。
一般来讲，M 的数量都会多于 P。像在 Go 中，M 的数量最大限制是 10000，P 的默认数量的 CPU 核数。另外由于 M 的属性，也就是如果存在系统阻塞调用，阻塞了 M，又不够用的情况下，M 会不断增加。
M 不断增加的话，如果本地队列挂载在 M 上，那就意味着本地队列也会随之增加。这显然是不合理的，因为本地队列的管理会变得复杂，且 Work Stealing 性能会大幅度下降。
M 被系统调用阻塞后，我们是期望把他既有未执行的任务分配给其他继续运行的，而不是一阻塞就导致全部停止。
因此使用 M 是不合理的，那么引入新的组件 P，把本地队列关联到 P 上，就能很好的解决这个问题。
总结
今天这篇文章结合了整个 Go 语言调度器的一些历史情况、原因分析以及解决方案说明。
”GMP 模型，为什么要有 P“ 这个问题就像是一道系统设计了解，因为现在很多人为了应对面试，会硬背 GMP 模型，或者是泡面式过了一遍。而理解其中真正背后的原因，才是我们要去学的要去理解。
知其然知其所以然，才可破局。
👆 点击关注煎鱼，在知识的海洋里遨游
学习资料分享，关注公众号回复指令：
本文分享自微信公众号 - 脑子进煎鱼了（eddycjy）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。