一文教你看懂Golang协程调度【GMP设计思想】

一文教你看懂Golang协程调度【GMP设计思想】

1 Golang调度器的由来

1.1 单进程的问题：进程阻塞、CPU浪费时间

1. 单一执行程序、计算机只能一个任务一个任务来进行处理
2. 进程阻塞所带来的CPU浪费时间

1.2 多进程、多线程问题：设计复杂、高内存、CPU占用

1. 设计变得复杂：
   • 进程/线程的数量越多，切换成本就越大，也就越浪费
   • 多线程往往伴随着同步竞争（如：锁、资源冲突等）
2. 多进程、多线程的壁垒
   • 高内存占用：
     - 进程占用内存（虚拟内存：4GB 32bitOS）
     - 线程占用内存（约4MB）
   • 高CPU调度消耗

1.3 协程co-routine的模式（M:N，依赖调度器的性能）

CPU本质是操控一个线程，只不过我们逻辑意义上将线程划分为了协程和内核空间的线程。然后我们通过编程语言来操控用户空间上的线程（协程）

①N:1方式：

• 无法利用多个CPU
• 出现阻塞的瓶颈
  ②1:1方式：
• 跟多线程/多进程模型无异
• 切换协程成本代价昂贵
  ③M:N方式：
• 能够利用多核
• 过于以来协程调度器的优化和算法

1.4 调度的优化

Goroutine的优化：

• 内存占用，几KB，可以大量开辟
• 灵活调度，切换成本低

早期Go调度器的弊端：

基于全局的Go队列和比较传统的轮询，利用多个thread去调度
弊端：

1. 创建、销毁、调度G（goroutine）都需要每个M获取锁，形成了激烈的资源竞争
2. M（thread）转移G会曹成延迟和额外的系统负载
3. 系统调用（CPU在M之间的切换）导致频繁的线程阻塞和取消阻塞

2 GMP模型的设计思想

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

2.1 GMP模型简介

①GMP：goroutine-processor-thread

G：goroutine 协程
P：processor 处理器
M：thread 内核线程

②全局队列：存放等待运行的G

存放等待运行的goroutine

③P的本地队列：存放等待运行的G

processer的本地队列：

• 存放等待运行的goroutine
• 数量限制：不超过256G
• 优先将新创建的goroutine放在P的本地队列中，如果本地队列放满了才会放在全局队列中

④P列表：程序启动时创建

• 程序启动时创建
• 最多有GOMAXPROCS个（可配置）

⑤M列表：当前OS分配到Go程序的内核线程数

当前操作系统分配到当前Go程序的内核线程数

⑥P和M的数量

1. P的数量：
   • 环境变量$GOMAXPROCS配置
   • 在程序中通过runtime.GOMAXPROCS()来设置
2. M的数量：
   • Go语言本身限定M最多1W
   • runtime/debug包中的SetMaxThreads函数来设置
   • 如果有一个M阻塞，会创建一个新的M
   • 如果有M空闲，那么就会回收或者睡眠一个M

2.2 调度器的设计策略

①复用线程：work stealing、hand off机制

避免频繁的创建、销毁线程，而是线程进行复用

• work stealing机制：当本线程无可运行的G时，会尝试从全局G中偷取G，如果全局队列为空，那么从其他线程绑定的P偷取G，而不是销毁空闲的线程【本地队列-全局队列-其他队列】
• hand off机制：当本线程因为G进行系统调用阻塞时，线程释放绑定的P，把P转移给其他空闲的线程执行。

②利用并行

GOMAXPROCS设置P的数量，最多有GOMAXPROCS个线程分布在多个CPU上同时运行

③抢占

在co-routine中要等待一个协程主动让出CPU才执行下一个协程，在Go中，一个goroutine最多占用CPU 10ms，防止其他goroutine被饿死

④全局G队列

当M执行work stealing它可以从全局G的队列获取G

• 本地队列没有可运行的goroutine,会有steal机制,从从其他P里获取可运行的G ,本地队列运行顺序为 先从本地队列查询,全局队列查询,然后再从其他P里偷取,具体源码在runtime的proc.go
  

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中摘除（detach），然后再创建一个新的操作系统的线程（如果有空闲的线程可复用空闲线程）来服务于这个P。
6. 当M系统调用结束的时候，这个G会尝试获取一个空闲的P执行，并放入到这个P的本地队列。如果获取不到P，那么这个线程M会变成休眠状态，加入到空闲线程中，然后这个G会被放入全局队列中。

2.4 调度器调度的生命周期：M0、G0

package main

import "fmt"

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

下面我们分析代码流程：

1. runtime创建最初的线程M0和G0，并把二者关联
2. 调度器初始化：初始化M0、栈、垃圾回收，以及创建和初始化由GOMAXPROCS个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程序的一生，runtime.main的goroutine执行之前都是为调度器做准备工作，runtime.main的goroutine运行，才是调度器的真正开始，直到runtime.main的结束而结束。

①M0：启动go程序后创建的第一个主线程

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

②G0：每个M启动后创建的第一个goroutine

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

2.5 GMP可视化调试（trace编程）

① 基本的trace编程

1. 创建trace文件 f,err := os.Create(“trace.out”)
2. 启动trace trace.Start(f)
3. 停止trace trace.Stop()
4. go build运行之后，会得到一个trace.out文件

trace/main.go:

package main

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

func main() {
    
    
	//1. 创建trace文件
	file, err := os.Create("trace.out")
	if err != nil {
    
    
		panic(err)
	}
	defer file.Close()
	//2. 开启trace
	trace.Start(file)
	//执行业务逻辑
	fmt.Println("do something...")
	//3. 暂停trace
	trace.Stop()
}

运行上面的程序之后会得到一个trace.out文件：

②通过go tool trace工具打开trace文件

1. go tool trace trace.out
2. 通过http://127.0.0.1:xxxx进行访问(端口是随机的)

点击页面上的view trace：

查看效果：

点击图表中不同的未知，查看左下方的值

1. G信息

点击Goroutines那一行可视化的数据条，我们会看到一些详细的信息。

一共有两个G在程序中，一个是特殊的G0，是每个M必须有的一个初始化的G，这个我们不必讨论。

其中G1应该就是main goroutine(执行main函数的协程)，在一段时间内处于可运行和运行的状态。

2. M信息

点击Threads那一行可视化的数据条，我们会看到一些详细的信息。

一共有两个M在程序中，一个是特殊的M0，用于初始化使用，这个我们不必讨论。

3. P信息

G1中调用了main.main，创建了trace goroutine g18。G1运行在P1上，G18运行在P0上。

这里有两个P，我们知道，一个P必须绑定一个M才能调度G。

4. M信息

我们会发现，确实G18在P0上被运行的时候，确实在Threads行多了一个M的数据，点击查看如下：

多了一个M2应该就是P0为了执行G18而动态创建的M2.

③通过Debug trace方式

main.go

package main

import (
    "fmt"
    "time"
)

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

# 编写
go build main.go
# 执行编译好的可执行文件
GODEBUG=schedtrace=1000 ./main 

# 查看输出结果
SCHED 0ms: gomaxprocs=2 idleprocs=0 threads=4 spinningthreads=1 idlethreads=1 runqueue=0 [0 0]
Hello World
SCHED 1003ms: gomaxprocs=2 idleprocs=2 threads=4 spinningthreads=0 idlethreads=2 runqueue=0 [0 0]
Hello World
SCHED 2014ms: gomaxprocs=2 idleprocs=2 threads=4 spinningthreads=0 idlethreads=2 runqueue=0 [0 0]
Hello World
SCHED 3015ms: gomaxprocs=2 idleprocs=2 threads=4 spinningthreads=0 idlethreads=2 runqueue=0 [0 0]
Hello World
SCHED 4023ms: gomaxprocs=2 idleprocs=2 threads=4 spinningthreads=0 idlethreads=2 runqueue=0 [0 0]
Hello World

● SCHED：调试信息输出标志字符串，代表本行是goroutine调度器的输出；
● 0ms：即从程序启动到输出这行日志的时间；
● gomaxprocs: P的数量，本例有2个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的数量。

3 GMP场景分析合集

3.1 G1创建G2：优先入本地队列

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

3.2 G1执行完毕调用G2：G0负责调度

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

3.3 G2开辟过多G

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

3.4 G2本地已经满继续创建G：打乱放全局队列

G2所绑定的队列已经满了，但此时又创建了新的G，则打乱本地队列的前半部分G和新创建的G一起放入全局队列。（保证：随机，避免新G饥饿。）
G2在创建G7的时候，发现P1的本地队列已满，需要执行负载均衡(把P1中本地队列中前一半的G，还有新创建G转移到全局队列)

• （实现中并不一定是新的G，如果G是G2之后就执行的，会被保存在本地队列，利用某个老的G替换新G加入全局队列）
• 这些G被转移到全局队列时，会被打乱顺序。所以G3,G4,G7被转移到全局队列。

3.5 G2本地未满创G8：放入本地队列

如果在创建新G之后本地队列未满，则先放本地队列。
G2创建G8时，P1的本地队列未满，所以G8会被加入到P1的本地队列。

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

3.6 创建G时会尝试环境其他空闲的M和P去消费新G

创建新G成功后，会尝试换唤醒M和P，让其组合来消费新G。
规定：在创建G时，运行的G会尝试唤醒其他空闲的P和M组合去执行。

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

3.7 从全局队列到P本地队列的LB（负载均衡）

自旋线程根据LB来从全局队列拉取G进行消费。
M2尝试从全局队列(简称“GQ”)取一批G放到P2的本地队列（函数：findrunnable()）。M2从全局队列取的G数量符合下面的公式

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

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

3.8 M2从M1偷取G

如果M2队列为空，则从M1的本地队列中偷取后半部分G进行消费。（好不容易偷一次）
假设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 自旋线程的最大限制:自旋+运行<=GOMAXPROCS

正在运行的线程+自旋的线程 <= GOMAXPROCS。
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 G发生系统调用或阻塞

P与阻塞的M解绑，去唤醒休眠中的M进行组合。
假定当前除了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 G发生系统调用或非阻塞

尝试获取之前解绑的P，如果之前的P已经与其他M组合，则尝试从空闲的P队列中获取新P。如果获取失败，则将阻塞结束的G放入全局队列
G8创建了G9，假如G8进行了非阻塞系统调用。

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

总结：Go调度器很轻量也很简单，足以撑起goroutine的调度工作，并且让Go具有了原生（强大）并发的能力。Go调度本质是把大量的goroutine分配到少量线程上去执行，并利用多核并行，实现更强大的并发。

参考：https://www.yuque.com/aceld/golang/srxd6d