Golang

关注公众号 jb51net

关闭
首页 > 脚本专栏 > Golang > Golang调度器GMP

Golang调度器GMP原理小结

作者：peace-chen

本文主要介绍了Golang调度器GMP原理小结,详细描述了Goroutine的创建、执行、阻塞、唤醒等场景下的调度过程,下面就来一起了解一下

​一、Golang “调度器” 的由来？

1.1 单进程时代不需要调度器

每个程序就是一个进程，知道一个程序运行结束，下一个进程才会执行，一切的程序只能串行发生

弊端：

1.2 多进程/线程时代有了调度器需求（TODO 进程和线程的区别）

一个进程阻塞CPU可以立刻切换到其他进程中去执行（解决阻塞的问题），而且调度CPU的算法可以保证在运行的进程都可以被分配到CPU的运行时间片。（宏观看，似乎多个进程是在同时被运行）
弊端：

1.3 协程来提高CPU利用率

优点：协程在用户态线程完成切换调度，不会陷入到内核态，切换轻量快速

一个“用户态线程”必须绑定一个“内核态线程”，但是CPU并不知道有“用户态线程”的存在，它只知道它运行的是一个“内核态线程”（Linux的PCB的进程控制块）。

再细分，内核线程依然叫“线程（Thread）”,用户态线程叫协程（co-routine）

既然一个协程（co-routine）可以绑定一个线程（Thread），那么能不能多个协程（co-routine）绑定一个或者多个线程（Thread）呢？基于以上思考，产生了以下三种协程和线程的映射关系；

1.3.1 N:1关系

N个协程绑定1个线程，即程序启动后只会创建一个调度线程，用来管理N个协程；

缺点：用不了硬件的多核加速能力，协程阻塞会导致线程阻塞，失去并发能力；

1.3.2 1:1关系

一个协程绑定一个线程

缺点：线程的创建、删除和切换的代价都是由CPU来完成的，代价高，和直接使用多线程方式来说，没带来多大提升，有种脱裤子放屁的感觉；

1.3.3 M:N关系

M个协程绑定N个内核线程，是N:1和1:1类型的结合，保留以上2种模型的优点情况下，同时客服了以上2种模型的缺点，实现较为复杂；

线程由CPU调度是抢占式的，协程由用户态调度是协作式的，一个协程让出CPU后，才能执行下一个协程；

1.4 Go语言的协程goroutine

Go使用的goroutine是来自协程的概念，让一组可复用的函数运行在一组线程之上，及时有协程阻塞，该线程的其他协程也可以被runtime调度，转移到其他可运行的线程上；
优点：

1.5 被废弃的goroutine调度器

go 2012之前的调度器被废弃，可以先看看之前的调度器存在的问题

M想要执行、放回G都必须访问全局的G队列，并且M有多个，即多线程访问同一资源需要加锁保证互斥/同步

弊端：

二、Goroutine调度器的CMP模型的设计思想

新调度器中，除了M（thread）和G（goroutine），又引进了P（Processor）

Processor：包含了运行goroutine的资源，如果线程想运行goroutine，必须先获取p，p中还包含了可运行的G队列

2.1 GMP模型

Go中，线程是运行goroutine的实体，调度器的功能是将可运行的goroutine分配到工作线程上；

Goroutine调度器和OS调度器是通过M结合起来的，每个M都代表了一个内核线程，OS调度器负责把内核线程分配到CPU的核上执行

2.1.1 有关P和M的个数问题

2.1.1.1 P

由启动时环境变量$GOAMXPROCES或者是由runtime的方法GOMAXPROCES()决定。这意味着在程序执行的任意时刻，都只有$GOMAXPROCES个goroutine在同时运行；

2.1.1.2 M

M与P的数量没有绝对的关系，一个M阻塞了，P就会去创建或者切换另一个M，所以，即使P的默认数量是1，也有可能会创建很多个M出来；

2.1.2 P和M何时会被创建

2.1.1.1 P

在确定了P的最大数量n后，运行是系统会根据这个数量创建n个p。

2.1.1.2 M

没有足够的M来关联P并运行其中的可运行的G。比如所有的M此时都被阻塞住了，而P中还有很多就绪任务，就会去寻找空闲的M，没有空闲的，就会去创建新的M。

2.2 调度器的设计策略

复用线程：避免频繁的创建、销毁线程，增加系统开销，而是对线程的复用。

2.3 go func()调度流程

  1. 我们通过go func()来创建一个goroutine；
  2. 有两个存储G的队列，一个是局部调度器P的本地队列、一个是全局G队列。新创建的G会先保存在P的本地队列中，如果P的本地队列已经满了，就会保存在全局的队列中；
  3. G只能运行在M中，一个M必须持有一个P，M与P是1:1的关系。M会从P的本地队列弹出一个可执行的G来执行，如果P的本地队列为空，就会尝试从其他的MP组合中偷取一个可执行的G来执行；
  4. 一个M调度G执行的过程是一个循环机制；
  5. 当M执行一个G的时候，如果发生了syscall或者其余阻塞操作，M会被阻塞，如果当前有一些G在执行，runtime会把这个线程M从P中摘除，然后再创建一个新的操作系统级别的线程（如果有空闲的线程就可以复用空闲线程）来服务与这个P；
  6. 当M系统调用结束时候，这个G会尝试获取一个空闲的P执行，并放入到这个P的本地队列中。如果获取不到P，那么这个线程M会变成休眠状态，加入到空闲线程中，然后这个G会被放入到全局队列中；

2.4 调度器的生命周期

M0：启动程序后的编号为 0 的主线程，这个 M 对应的实例会在全局变量 runtime.m0 中，不需要在 heap 上分配，M0 负责执行初始化操作和启动第一个 G， 在之后 M0 就和其他的 M 一样了。

G0：每次启动一个 M 都会第一个创建的 goroutine，G0 仅用于负责调度的 G，G0 不指向任何可执行的函数，每个 M 都会有一个自己的 G0。在调度或系统调用时会使用 G0 的栈空间，全局变量的 G0 是 M0 的 G0。

追踪代码：

package main
import "fmt"
func main() {
    fmt.Println("Hello world")
}
  1. runtime创建最初的线程m0和goroutine g0，并把2者关联；
  2. 调度器初始化：初始化m0、栈、垃圾回收，以及创建和初始化由GOMAXPROCES个P构成的P列表；
  3. 实例代码中的main函数是main.main，runtime中也有一个main函数——runtime.main，代码经过编译后，runtime.main会调用main.main，程序启动时会为runtime.main创建goroutine，称它为main goroutine吧，然后把main goroutine加入到P的本地队列；
  4. 启动m0，m0已经绑定了P，会从P的本地队列中获取G，获取到main goroutine；
  5. G拥有栈，M根据G中的栈信息和调度信息设置运行环境；
  6. M运行G；
  7. G退出，再次回到M获取可运行的G，这样重复下去，直到main.main退出，runtime.main执行defer和panic处理，或者调用runtime.exit退出程序；​

三、Go调度器调度场景过程全解析

3.1 场景一

P拥有G1，M1获取P后开始运行G1，G1使用go func()创建了G2，为了局部性，G2优先加入到P1的本地队列；

3.2 场景二

G1运行完成后（函数：goexit），M1上运行的goroutine切换为G0，G0负责调度时协程的切换（函数：scheduler）。从P的本地队列获取G2，从G0切换到G2，并开始运行G2（函数：excute）。实现了线程M1的复用；

3.3 场景三

假设每个P的本地队列只能存3个G。G2要创建6个G，前三个G（G3,G4,G5）已经加入到P1的本地队列中，此时P1的本地队列满了；

3.4 场景四

G2 在创建 G7 的时候，发现 P1 的本地队列已满，需要执行负载均衡 (把 P1 中本地队列中前一半的 G，还有新创建 G 转移到全局队列)
（实现中并不一定是新的 G，如果 G 是 G2 之后就执行的，会被保存在本地队列，利用某个老的 G 替换新 G 加入全局队列）

这些G被转移到全局队列时，会被打乱顺序，所以G3,G4,G7被转移到全局队列中的顺序无规则；

3.5 场景五

G2创建G8时，P1的本地队列未满，所以G8会被加入到P1的本地队列中

G8 加入到 P1 点本地队列的原因还是因为 P1 此时在与 M1 绑定，而 G2 此时是 M1 在执行。所以 G2 创建的新的 G 会优先放置到自己的 M 绑定的 P 上

3.6 场景六

在创建G时，运行的G会尝试唤醒其他空闲的P和M组合去执行；

假定 G2 唤醒了 M2，M2 绑定了 P2，并运行 G0，但 P2 本地队列没有 G，M2 此时为自旋线程（没有 G 但为运行状态的线程，不断寻找 G）

3.7 场景七

M2 尝试从全局队列 (简称 “GQ”) 取一批 G 放到 P2 的本地队列（函数：findrunnable()）。M2 从全局队列取的 G 数量符合下面的公式：

n = min(len(GQ)/GOMAXPROCS + 1, len(GQ/2))

至少从全局队列取 1 个 g，但每次不要从全局队列移动太多的 g 到 p 本地队列，给其他 p 留点。这是从全局队列到 P 本地队列的负载均衡


假定我们场景中一共有 4 个 P（GOMAXPROCS 设置为 4，那么我们允许最多就能用 4 个 P 来供 M 使用）。所以 M2 只从能从全局队列取 1 个 G（即 G3）移动 P2 本地队列，然后完成从 G0 到 G3 的切换，运行 G3

3.8 场景八

假设 G2 一直在 M1 上运行，经过 2 轮后，M2 已经把 G7、G4 从全局队列获取到了 P2 的本地队列并完成运行，全局队列和 P2 的本地队列都空了，如场景 8 图的左半部分

全局队列已经没有 G，那 m 就要执行 work stealing (偷取)：从其他有 G 的 P 哪里偷取一半 G 过来，放到自己的 P 本地队列。P2 从 P1 的本地队列尾部取一半的 G，本例中一半则只有 1 个 G8，放到 P2 的本地队列并执行；

3.9 场景九

G1 本地队列 G5、G6 已经被其他 M 偷走并运行完成，当前 M1 和 M2 分别在运行 G2 和 G8，M3 和 M4 没有 goroutine 可以运行，M3 和 M4 处于自旋状态，它们不断寻找 goroutine。

为什么要让 m3 和 m4 自旋，自旋本质是在运行，线程在运行却没有执行 G，就变成了浪费 CPU. 为什么不销毁现场，来节约 CPU 资源。因为创建和销毁 CPU 也会浪费时间，我们希望当有新 goroutine 创建时，立刻能有 M 运行它，如果销毁再新建就增加了时延，降低了效率。当然也考虑了过多的自旋线程是浪费 CPU，所以系统中最多有 GOMAXPROCS 个自旋的线程 (当前例子中的 GOMAXPROCS=4，所以一共 4 个 P)，多余的没事做线程会让他们休眠。

3.10 场景十

假定当前除了 M3 和 M4 为自旋线程，还有 M5 和 M6 为空闲的线程 (没有得到 P 的绑定，注意我们这里最多就只能够存在 4 个 P，所以 P 的数量应该永远是 M>=P, 大部分都是 M 在抢占需要运行的 P)，G8 创建了 G9，G8 进行了阻塞的系统调用，M2 和 P2 立即解绑，P2 会执行以下判断：如果 P2 本地队列有 G、全局队列有 G 或有空闲的 M，P2 都会立马唤醒 1 个 M 和它绑定，否则 P2 则会加入到空闲 P 列表，等待 M 来获取可用的 p。本场景中，P2 本地队列有 G9，可以和其他空闲的线程 M5 绑定

3.11 场景十一

G8 创建了 G9，假如 G8 进行了非阻塞系统调用

M2 和 P2 会解绑，但 M2 会记住 P2，然后 G8 和 M2 进入系统调用状态。当 G8 和 M2 退出系统调用时，会尝试获取 P2，如果无法获取，则获取空闲的 P，如果依然没有，G8 会被记为可运行状态，并加入到全局队列，M2 因为没有 P 的绑定而变成休眠状态 (长时间休眠等待 GC 回收销毁)。

到此这篇关于Golang调度器GMP原理小结的文章就介绍到这了,更多相关Golang调度器GMP内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

您可能感兴趣的文章:
阅读全文