Golang 19_Golang调度GMP模型

一、GMP模型简介

1.1 GMP模型简介

GMP 是 Golang 的线程模型，主要包括以下三部分：:

Goroutine（G）：是 Golang 中轻量级的并发执行单元，类似于线程但比线程更小、更灵活；每个 goroutine 都有自己独立的堆栈和寄存器等信息，可以通过 go 关键字创建并发执行任务；Goroutine 由 Go运行时（runtime）进行调度和管理；
Operating System Thread（M）：操作系统线程，是实际的执行单元，负责将 goroutine 调度到逻辑处理器上执行。Go 程序中通常会创建多个 M，以便在多核 CPU 上实现并发执行；
Logical Processor（P）：这是 Golng 中的逻辑处理器（虚拟处理器），是一个虚拟的执行单元，M 执行 G 所需要的资源和上下文，负责调度和管理 Goroutine；只有将 P 和 M 绑定，才能让 P 的 runq 中的 G 真正运行起来，P 相当于一个调度器，它会将 Goroutine分配给 M 执行；一个 Go 程序可以有多个 P，以便并行执行多个Goroutine；P 的数量决定了系统内最大可并行的 G 的数量，P的数量受本机的CPU核数影响，可通过环境变量$GOMAXPROCS或在runtime.GOMAXPROCS()来设置，默认为CPU核心数；

GMP模型的本质是将一组 Goroutine分配调度到一组 M线程中去执行，是通过 P调度器来管理并调度G 到 M 上执行；当一个Goroutine被创建时，它首先会被放入到 P的队列中，等待 M线程来执行；M线程会从 P的队列中取出一个 Goroutine 并执行，如果执行过程中发生阻塞，M线程会放弃该 Goroutine的执行，并将其重新放回到 P的队列中，等待后续的调度。

在 Golang 中，操作系统线程(M) 是运行 Goroutine(G)的实体，调度器(P) 的功能是把可运行的 Goroutine 分配到工作线程(M)上运行。

全局队列（Global Queue）：存放等待运行的G（goroutine）；
P 的本地队列：同全局队列类似，存放的也是等待运行的G，存的数量有限，不超过256个，P 调度的 G 新建G’ 时，G’ 优先加入到 P 的本地队列，如果队列满了，则会把本地队列中一半的 G 移动到全局队列；
P列表：所有的 P 都在程序启动时创建，并保存在数组中，最多有GOMAXPROCS(可配置)个 P；
M：线程(M) 想运行任务就得获取 P，从 P 的本地队列获取 G，P 队列为空时，M也会尝试从全局队列拿一批 G 放到 P 的本地队列，或从其它 P 的本地队列拿一半放到自己 P 的本地队列。M 运行 G，G 执行之后，M 会从 P 获取下一个 G，不断重复下去；

P 和 M 的数量问题：

P的数量：通过环境变量$GOMAXPROCS设置；在程序中通过 runtime.GOMAXPROCS() 来设置；
M的数量：GO语言本身限定一万 (但是操作系统达不到)；通过runtime/debug包中的 SetMaxThreads函数来设置；有一个 M 阻塞，会创建一个新的 M；如果有 M 空闲，那么就会回收或者休眠；

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

1.2 GMP的调度流程

GMP 调度器采用抢占式的协作调度，具体调度流程如下：：

主线程启动，在主线程中创建一个操作系统线程（M）和一个逻辑处理器（P）；
当有 Goroutine 函数被调用时，它会被放入到一个全局队列中等待执行；
P 从全局队列中获取任务并执行；如果 P 执行的 goroutine 阻塞（例如在等待 I/O 完成），则该 P 的所有 goroutine 都会被暂停，P 会将自己标记为阻塞状态并开始寻找其它可用的 P；
如果没有可用的 P，则 M 变为自由线程，并且会去创建一个新的 P，以便执行未完成的 goroutine；新的 P 将加入到一个全局 P 列表中，而 M 将继续尝试在列表中寻找可用的 P；
当 goroutine 阻塞时，Goroutine 在堆上分配一块内存来保存其状态，并被添加到相关的等待队列中；而主线程会进入休眠状态，等待唤醒事件发生；
当阻塞的 goroutine 可以继续执行时，调度器会将它从等待队列中移除，并将其重新添加到全局队列中，等待 P 来执行；
当程序结束时，所有未完成的 goroutine 都会被杀死，而 P 和 M 也会被回收；

二、Golang 调度器策略详解

2.1 复用线程

Golang 在复用线程上主要体现在 work stealing机制（偷别人的去执行）和 hand off机制（自己放弃执行）。

work stealing机制 是指通过工作窃取方式来提升效率，充分利用线程进行并行计算，并减少了线程间的竞争。干完活的线程与其等着，不如去帮其它线程干活，于是它就去其它线程的队列里窃取一个任务来执行。而在这时它们会访问同一个队列，所以为了减少窃取任务线程和被窃取任务线程之间的竞争，通常会使用双端队列，被窃取任务线程永远从双端队列的头部拿任务执行，而窃取任务的线程永远从双端队列的尾部拿任务执行。

hand off机制 是指当本线程(M1)因为G进行系统调用阻塞时，线程释放绑定的P，把P转移给其它空闲的线程执行，此时M1如果长时间阻塞，可能会执行睡眠或销毁。

2.2 利用并行

可以使用GOMAXPROCS设置P的数量，这样的话最多有GOMAXPROCS个线程分布在多个CPU上同时运行。GOMAXPROCS也限制了并发的程度，比如GOMAXPROCS = 核数/2，则最多利用了一半的CPU核进行并行。

GOMAXPROCS 一般设置为 CPU核数或 CPU核数 -1。

2.3 抢占策略

1 对 1 模型的调度器，需要等待一个co-routine主动释放后才能轮到下一个进行使用。

Golang中，如果一个goroutine使用10ms还没执行完，CPU资源就会被其它goroutine所抢占。

2.4 全局G队列

全局 G队列其实是复用线程的补充，当工作窃取时，优先从全局队列去取，取不到才从别的 P本地队列取（1.17版本）。

在新的调度器中依然有全局G队列，但功能已经被弱化了，当M执行work stealing从其它P偷不到G时，它可以从全局G队列获取G。

三、goroutine 的调度过程及调度器的生命周期

3.1 goroutine（go func()）的调度过程

Golang 通过 go func() 来创建一个goroutine运行，其流程如下图：

通过go func()来创建一个goroutine；
有两个存储 G 的队列，一个是局部调度器 P 的本地队列、一个是全局 G队列。新创建的G会先保存在P的本地队列中，如果 P的本地队列已经满了就会保存在全局的队列中；
G 只能运行在M中，一个 M 必须持有一个P，M 与 P 是 1 ：1的关系。M 会从 P的本地队列弹出一个可执行状态的 G来执行，如果 P的本地队列为空，则从全局队列获取 G，如果全局队列也为空，则从另一个 P 的本地队列偷取一半数量的 G（负载均衡）来执行，这种从其它 P偷的方式称之为 work stealing；
一个 M 调度 G 执行的过程是一个循环机制：

在执行 G 的过程发生系统调用阻塞（同步），会阻塞G和M（操作系统限制），此时P会和当前M解绑，并寻找新的M，如果没有空闲的M就会新建一个M ，接着继续执行 P中其余的G，这种阻塞后释放P的方式称之为 hand off；
系统调用结束后，这个阻塞的G会尝试获取一个空闲的P执行，优先获取之前绑定的P，并放入到这个P的本地队列，如果获取不到P，那么这个线程M变成休眠状态，加入到空闲线程中，然后这个G会被放入到全局队列中；
如果M在执行G的过程发生网络IO等操作阻塞时（异步），阻塞G，不会阻塞M，M会寻找P中其它可执行的G继续执行，G会被网络轮询器network poller 接手，当阻塞的G恢复后，G 从network poller 被移回到P的 LRQ 中，重新进入可执行状态；异步情况下，通过调度，Go scheduler 成功地将 I/O 的任务转变成了 CPU 任务，或者说将内核级别的线程切换转变成了用户级别的 goroutine 切换，大大提高了效率；
M执行完G后清理现场，重新进入调度循环（将M上运⾏的goroutine切换为G0，G0负责调度时协程的切换）；

3.2 调度器的生命周期

在了解调度器生命周期之前，需要了解两个新的角色 M0 和 G0，M0 和 G0 都是放在全局空间的。 M0（跟进程数量绑定，一比一）：

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

G0（每个M都会有一个G0）：

每次启动一个M，都会第一个创建的gourtine，就是G0；
G0仅用于负责调度G；例如：从 G1 切换到 G2 时，会先切回到 G0，保存 G1 的栈等调度信息，然后再切换到 G2；
G0不指向任何可执行的函数；
每个M都会有一个自己的G0；
全局变量的G0是M0的G0；
在调度或系统调用时会使用G0的栈空间，再通过G0进行调度

具体流程为：来分析一段代码：

1
2
3
4
5
6
7


package main

import "fmt"

func main() {
    fmt.Println("Hello world")
}

runtime创建最初的线程m0和goroutine g0，并把二者关联。
调度器初始化：初始化m0、栈、垃圾回收，以及创建和初始化由GOMAXPROCS个P构成的P列表。
示例代码中的main函数是main.main，runtime中也有1个main函数——runtime.main，代码经过编译后，runtime.main会调用main.main，程序启动时会为runtime.main创建goroutine，称它为main goroutine吧，然后把main goroutine加入到P的本地队列。
启动m0，m0已经绑定了P，会从P的本地队列获取G，获取到main goroutine。
G拥有栈，M根据G中的栈信息和调度信息设置运行环境。
M 运行 G。
G退出，再次回到M获取可运行的G，这样重复下去，直到main.main退出，runtime.main执行Defer和Panic处理，或调用runtime.exit退出程序。

调度器的生命周期几乎占满了一个Go程序的一生，runtime.main的goroutine执行之前都是为调度器做准备工作，runtime.main的goroutine运行，才是调度器的真正开始，直到runtime.main结束而结束。

四、GMP 调度场景分析

4.1 G1创建G3

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

4.2 G1执行完毕

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

4.3 G溢出

假设每个P的本地队列只能存4个G。G2要创建了6个G，前4个G（G3, G4, G5,G6）已经加入P1的本地队列，P1本地队列满了

G2在创建G7的时候，发现P1的本地队列已满，需要执行负载均衡（把P1中本地队列中前一半的G，还有新创建G转移到全局队列）

移走前一半的G是为了防止后面G饥饿这些G被转移到全局队列时，会被打乱顺序。所以G3,G4,G7被转移到全局队列。 G2创建G8时，P1的本地队列未满，所以G8会被加入到P1的本地队列

4.4 唤醒正在休眠的M

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

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

先从全局队列中获取，没有再从其它线程中偷取（先全后偷）

4.5 自旋线程获取G

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

1

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

GQ：全局队列总长度（队列中现在元素的个数）
GOMAXPROCS：p的个数

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

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

当M2有了新的G（不再是G0），便不是自旋线程了。相关源码参考：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37


// 从全局队列中偷取，调用时必须锁住调度器
func globrunqget(_p_ *p, max int32) *g {
    // 如果全局队列中没有 g 直接返回
    if sched.runqsize == 0 {
        return nil
    }

    // per-P 的部分，如果只有一个 P 的全部取
    n := sched.runqsize/gomaxprocs + 1
    if n > sched.runqsize {
        n = sched.runqsize
    }

    // 不能超过取的最大个数
    if max > 0 && n > max {
        n = max
    }

    // 计算能不能在本地队列中放下 n 个
    if n > int32(len(_p_.runq))/2 {
        n = int32(len(_p_.runq)) / 2
    }

    // 修改本地队列的剩余空间
    sched.runqsize -= n
    // 拿到全局队列队头 g
    gp := sched.runq.pop()
    // 计数
    n--

    // 继续取剩下的 n-1 个全局队列放入本地队列
    for ; n > 0; n-- {
        gp1 := sched.runq.pop()
        runqput(_p_, gp1, false)
    }
    return gp
}

4.6 M2从M1中偷取G

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

偷取队列元素的一半

4.7 自旋线程的最大限制

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

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

4.8 G发生系统调用/阻塞

假定当前除了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绑定

自旋线程抢占G，不抢占P

4.9 G发送系统调用/非阻塞

上述G8如果执行完毕，此时M2会首先寻找之前的P，如果没有则尝试从空闲p队列中获取，如果没获取不到，会进入M阻塞队列中（长时间休眠等待GC回收销毁）

Tips: 原文 https://blog.csdn.net/fengxiandada/article/details/129461300

五、可视化的CMP编程

5.1 trace方式

要使用trace编程，分三步走：

创建trace文件：f, err := os.Create(“trace.out”)
启动trace：err = trace.Start(f)
停止trace：trace.Stop()

然后再通过go tool trace工具打开trace文件：

1

go tool trace trace.out

示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


package main

import (
    "fmt"
    "os"
    "runtime/trace"
)

// trace的编码过程
// 1. 创建文件
// 2. 启动
// 3. 停止
func main() {
    // 1.创建一个trace文件
    f, err := os.Create("trace.out")
    if err != nil {
        panic(err)
    }
    defer func(f *os.File) {
        err := f.Close()
        if err != nil {
            panic(err)
        }
    }(f)
    // 2. 启动trace
    err = trace.Start(f)
    if err != nil {
        panic(err)
    }
    // 正常要调试的业务
    fmt.Println("hello GMP")
    // 3. 停止trace
    trace.Stop()
}

启动后打开网页点击view trace，然后就能看到分析信息。

5.2 debug方式

使用debug方式可以不需要trace文件。示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


// debug.go
package main

import (
    "fmt"
    "time"
)

func main() {
    for i := 0; i < 5; i++ {
        time.Sleep(time.Second)
        fmt.Println("hello GMP")
    }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


192:CodeTest mac$ go build debug.go
192:CodeTest mac$ GODEBUG=schedtrace=1000 ./debug
SCHED 0ms: gomaxprocs=6 idleprocs=3 threads=5 spinningthreads=1 needspinning=0 idlethreads=0 runqueue=0 [1 0 0 0 0 0]
hello GMP
SCHED 1007ms: gomaxprocs=6 idleprocs=6 threads=5 spinningthreads=0 needspinning=0 idlethreads=3 runqueue=0 [0 0 0 0 0 0]
hello GMP
SCHED 2010ms: gomaxprocs=6 idleprocs=6 threads=5 spinningthreads=0 needspinning=0 idlethreads=3 runqueue=0 [0 0 0 0 0 0]
hello GMP
SCHED 3018ms: gomaxprocs=6 idleprocs=6 threads=5 spinningthreads=0 needspinning=0 idlethreads=3 runqueue=0 [0 0 0 0 0 0]
hello GMP
SCHED 4020ms: gomaxprocs=6 idleprocs=6 threads=5 spinningthreads=0 needspinning=0 idlethreads=3 runqueue=0 [0 0 0 0 0 0]
hello GMP

SCHED：调试信息输出标志字符串，代表本行是goroutine调度器的输出；
0ms：即从程序启动到输出这行日志的时间；
gomaxprocs: P的数量，本例有6个P, 因为默认的P的属性是和cpu核心数量默认一致，当然也可以通过GOMAXPROCS来设置；
idleprocs: 处于idle状态的P的数量；通过gomaxprocs和idleprocs的差值，我们就可知道执行go代码的P的数量；
threads: os threads/M的数量，包含scheduler使用的m数量，加上runtime自用的类似sysmon这样的thread的数量；
spinningthreads: 处于自旋状态的os thread数量；
idlethread: 处于idle状态的os thread的数量；
runqueue=0： Scheduler全局队列中G的数量；
[0 0]: 分别为2个P的local queue中的G的数量。