关于golang:图解协程调度模型GMP模型

当初无论是客户端、服务端或 web 开发都会波及到多线程的概念。那么大家也晓得，线程是操作系统可能进行运算调度的最小单位，同一个过程中的多个线程都共享这个过程的全副系统资源。

线程

三个基本概念

• 内核线程：在内核空间实现的线程，由内核治理
• 用户线程：在用户空间实现的线程，不归内核治理，由用户态实现治理
• 轻量级过程（LWP）：在内核中反对用户线程（用户线程与内核线程的中间层，内核线程的高度形象）

线程模型

1. 一对一模型（内核级线程模型）
   
   由过程创立 LWP，因为每个 LWP 对应一个内核级线程，所以用户也就是在创立一个一个内核线程，由内核治理线程。咱们熟知的大多数语言就是属于一对一模型，比方 C#、java、c 等（这些语言也有相应的形式实现用户态线程，只是语言自身的线程是一对一模型）

2. 一对多模型（用户级模型）
   
   用户过程创立多个用户级线程对应在同一个 LWP 上，所以实质上在内核态只会有一个内核线程运行，那么用户及线程的调度就是在用户态通过用户空间的线程库对线程进行治理。

   这类模型长处就是调度在用户态，所以不必频繁地进行内核态与用户态切换，大大晋升线程效率。python 语言的协程就是这种模型实现的，然而这种模型并不能实现真正意义上的的并发。

3. 多对多模型（用户级与内核级线程模型）
   
   多对多模型也就是在上述两个模型根底上做一些长处的汇合。用户态的多个线程对应多个 LWP，但它们之间不是一一对应的，在用户态治理调度每个 LWP 对应的用户线程绑定关系。

   所以多对多模型是能够有更多的用户态线程在绝对于比拟少的内核线程上运行的。这种用户态线程也就是咱们平时说的协程。Go 语言的协程就是多对多模型，它由 Go 语言的 runtime 在用户态做调度，这也是 Go 语言高并发的起因。

协程（Goroutine）

后面咱们说到，协程就是用户态线程，它的所有调度都在用户态实现，协程这方面 Go 语言应该是最具代表性的（毕竟以高并发为卖点），以 Go 语言的协程 –Goroutine 作为钻研对象。

GM 模型

在 Go 语言设计的初期，Go 团队应用简略的 GM 模型实现协程。

G：goroutine，也就是协程，它个别所占的栈内存为 2KB，运行过程中如果栈空间不够用则会主动扩容。它能够被了解成一个被打包的代码段。goroutine 并不是一个执行单元。

M：machine 工作线程，就是真正用来执行代码的线程。由 Go 的 runtime 治理好它的生命周期。

在 Go 语言初期应用一个全局的队列来保留所有的 G。当用户新建一个 G 的时候，runtime 就会将打包好的 G 放到全局队列的队尾，并保护好队尾指针。当 M 执行完一个 G 后，就会到全局队列的队头取一个 G 给 M 执行，并且保护好全局队列的队头指针。

能够发现这里有个很重大的问题，如果放任随便退出 G，也放任任何 M 随便取 G，那么就会呈现并发问题。解决并发问题很简略，就是加锁，Go 语言团队也的确是这样做的。那么加了锁之后也就代表所有的存取操作都会波及到这个繁多的全局互斥锁，那整个调度的执行效率大打折扣。除了锁导致性能问题以外，还有相似零碎调用时，工作线程常常被阻塞和勾销阻塞，等等一些问题[2]。所以后续官网团队调整了调度模型，退出了 P 的概念。

GMP 模型

新的模型中引入了 P 的概念，G 与 M 没有什么大的变动。

P：process 处理器，代表了 M 所需的上下文环境，也能够了解为一个 M 运行所须要的Token，当 P 有工作时须要创立或者唤醒一个 M 来执行它队列里的工作。所以 P 的数量决定了并行执行工作的数量，能够通过 runtime.GOMAXPROCS 来设定，当初的 Go 版本中默认为 CPU 的外围数。

上图依据曹大的 GMP 模型图自行简化绘制的。

P 构造：一个 P 对应一个 M，P 构造中带有runnext 字段和一个本地队列，runnext 字段中存储的就是下一个被 M 执行的 G，每个 P 带有一个 256 大小的本地数组队列，这个队列是无锁的，这两个数据结构相似于缓存的概念，能够无效的解决全局队列被频繁拜访的问题，而且 runnext 和本地队列是 PM 构造本地的，没有其余的执行单元竞争，所以也不必加锁。

M 构造：

runtime 中有两个非凡的 M：

①是 主线程，它专门用来解决主线逻辑；

②是一个 监控线程 sysmon，它不须要 P 就能够执行，监控线程外面是一个死循环，一直地检测是否有阻塞或者执行工夫过长的 G，发现之后将抢占这些 G。

一般的 M：

一般的 M 会有很多个，闲暇的 M 会被放在全局调度器的 m idle（m 闲暇）链表 中，在须要 m 的时候会优先从这里取，取不到的话就会创立新的 M， M 创立后就不会销毁 了。每个 M 构造有三个 G，gsignal 是 M 专门解决 runtime 的信号的 G，能够解决一些唤醒机制，G0 是在执行 runtime 调度代码的时候须要切换到的 G，还有一个 G 就是以后 M 须要执行的用户逻辑的 G。

M 有几种状态:

• 自旋中(spinning): 临时还没找到 Goroutine 来执行，然而正在找的一个状态。有这个状态和 nmsping 的计数，可能帮 runtime 判断是不是须要再启动额定的线程来执行 goroutine；
• 执行 go 代码中: M 正在执行 go 代码, 这时候 M 会领有一个 P；
• 执行原生代码中: M 正在执行原生代码或者阻塞的 syscall, 这时 M 并不领有 P；
• 休眠中: M 发现无待运行的 G 时会进入休眠，并增加到闲暇 M 链表中, 这时 M 并不领有 P。

调度

整体的调度流程就是一个生产生产过程。用户作为生产者，用户起了一个 goroutine 后，被打包成一个 G，通过 runtime 的一系列调度后被 M 生产。

生产端

生产过程次要是指将一个打包好的 G 放入到队列中的过程。如果以后的本地队列满的话，就会将打包的 batch 放到全局队列中。

生产端

生产过程相较于生产过程简单十分多，次要形容 P 和 M 怎么被调度，最终由 M 实现执行的过程。

后面咱们说到，每个 M 中有一个非凡的 G0 用来做调度，能够了解成当咱们的 M 没有执行完一个 G 后，须要切换到 G0 的栈空间，开始调用 schedule 函数找一个 G 来执行，找到后就切到找到的 G 的栈空间，并且执行它。

这边留神到，在每次执行的时候，会有一个变量在一直的 ++，这个 schedtick 咱们会在每次 schedule 函数调度 G 的时候用到，接下来咱们就来看看，每次调用 schedule 函数是如何找 G 的。

能够从图中看到，整个寻找可执行 G 的过程，这个过程中只有找到 G，就会完结 schedule，返回拿到的 G 去执行。

1. 在 schedule 函数中会判断 schedtick%61 == 0，也就是每 61 次（为什么是 61 次？我也不晓得，算是个魔法数字，凭作者本人的思考）就去全局队列取一次（确保全局队列中的 G 会被执行到）。否则咱们就去以后 M 绑定的 P 的队列中拿，当然优先执行 runnext 中的 G。
2. 当本地队列中找不到可用的 G 的时候咱们就会进入一个 findrunnable 的函数专门用来找 G。
3. 进入 findrunnable 中首先也是先在以后绑定的 P 的 runnext 和本地队列中寻找。
4. 从全局队列中获取，获取的数量是 全局队列的长度 /gomaxprocs+1，然而最大只能拿 128 个 G 到本地队列中，并拿出一个执行。
5. 从 netpoll 网络轮询器（监控网络 I / O 和文件 I / O 等耗时操作的）中获取阻塞的 G 继续执行。
6. work stealing，去其余 P（随机算法随机选中的）的本地队列中窃取 G 到本人这边，窃取的数量是被窃取队列的一半。
7. 再次尝试去全局队列获取。
8. 查看所有闲暇的 P 队列，如果有可运行的 G，就去绑定到那个 P 并执行。

9. 再次尝试去 netpoll 中获取。

   最初，在整个 findrunnable 中都没有找到能够执行的 G，以后的 M 就会进入休眠，并放到全局 M 链表中期待唤醒。

本文中，疏忽了 GC 方面解决以及很多细节解决，真正的调度流程是非常复杂的，Go 语言的官网代码是开源的并且有具体的正文，并且在 Go 版本升级过程中也会对一些逻辑有所调整，请自行留神时效性（本文基于 Go1.15）

References

[1]https://mp.weixin.qq.com/s/Nb… “ 过程、线程与协程傻傻分不清？一文带你吃透！”
[2]https://docs.google.com/docum… “Scalable Go Scheduler Design Doc”