当初无论是客户端、服务端或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”