Golang的GMP模型

一、调度器的由来和分析

单进程时代的两个问题：

• 单一执行流程、计算机只能一个任务一个任务处理
• 进程阻塞所代理的CPU浪费时间

多进程和多线程的问题：

多进程/多线程解决了阻塞问题
但是引入了新的问题
进程/线程的数量越多，切换成本就越大，也就越浪费


多线程随着同步竞争（如锁、竞争资源冲突等）开发设计变得越来越复杂

老的调度器的几个缺点：

• 创建、销毁、调度G都需要每个M获取锁，这就形成了激烈的锁竞争
• M转移G会造成延迟和额外的系统负载
• 系统调用（CPU在M之间的切换）导致频繁的线程阻塞和取消阻塞操作增加了系统开销
  

二、GMP模型简介

GMP:

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

全局队列：

存放等待运行的G

P的本地队列：

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

P列表：

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

M列表：

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

P和M的数量：

P的数量问题：

• 环境变量$GOMAXPROCS
• 在程序中通过runtime.GOMAXPROCS()来设置

M的数量问题：

• Go语言本身，是限定M的最大量是10000(忽略)
• runtime/debug包中的SetMaxThreads函数来设置
• 有一个M阻塞，会创建一个新的M
• 如果有M空闲，那么就会回收或者睡眠

三、调度器的设计策略

复用线程：

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

• work stealing线程：当本线程无可运行的G时，尝试从其他线程绑定的P偷取G，而不是销毁线程
• hand off机制：当本线程因为G进行系统调用阻塞时，线程释放绑定的P，把P转移给其他空闲的线程执行

利用并行：

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

抢占：

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

全局G队列：

当M执行work stealing从其他P偷不到G时，它可以从全局G队列获取G

四、go指令的调度过程

1. 我们通过go func()来创建一个goroutine
2. 有两个存储G的队列，一个是局部调度器P的本地队列、一个是全局G队列。新创建的G会先保存在本地队列中，如果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会被放入全局队列中
   

五、Go的启动周期M0和G0

M0：

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

G0：

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

六、GMP可视化调试

有2种方式可以查看一个程序的GMP的数据。

方式1：go tool trace

trace记录了运行时的信息，能提供可视化的Web页面。
简单测试代码：main函数创建trace，trace会运行在单独的goroutine中，然后main打印"Hello World"退出。

trace.go

package main

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

func main() {

    //创建trace文件
    f, err := os.Create("trace.out")
    if err != nil {
        panic(err)
    }

    defer f.Close()

    //启动trace goroutine
    err = trace.Start(f)
    if err != nil {
        panic(err)
    }
    defer trace.Stop()

    //main
    fmt.Println("Hello World")
}

运行程序

$ go run trace.go 
Hello World

会得到一个trace.out文件，然后我们可以用一个工具打开，来分析这个文件。

$ go tool trace trace.out 
2020/02/23 10:44:11 Parsing trace...
2020/02/23 10:44:11 Splitting trace...
2020/02/23 10:44:11 Opening browser. Trace viewer is listening on http://127.0.0.1:33479

我们可以通过浏览器打开http://127.0.0.1:33479网址，点击view trace 能够看见可视化的调度流程。

G信息

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

一共有两个G在程序中，一个是特殊的G0，是每个M必须有的一个初始化的G，这个我们不必讨论。
其中G1应该就是main goroutine(执行main函数的协程)，在一段时间内处于可运行和运行的状态。

M信息

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

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

P信息

G1中调用了main.main，创建了trace goroutine g18。G1运行在P1上，G18运行在P0上。
这里有两个P，我们知道，一个P必须绑定一个M才能调度G。
我们在来看看上面的M信息。

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

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

方式2：Debug trace

package main

import (
    "fmt"
    "time"
)

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

编译
go build trace2.go
通过Debug方式运行

$ GODEBUG=schedtrace=1000 ./trace2 
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的数量。

七、GMP调取器场景过程全分析

场景1：创建G

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

场景2：G执行完毕

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

场景3：G2开辟过多的G

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

场景4：G2本地满再创建G7

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

（实现中并不一定是新的G，如果G是G2之后就执行的，会被保存在本地队列，利用某个老的G替换新G加入全局队列）

这些G被转移到全局队列时，会被打乱顺序。所以G3,G4,G7被转移到全局队列。

场景5：G2本地未满创建G8

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

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

场景6：唤醒正在休眠的M

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

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

场景7：被唤醒的M从全局取G

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

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

相关源码参考：

// 从全局队列中偷取，调用时必须锁住调度器
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
}

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

假定我们场景中一共有4个P（GOMAXPROCS设置为4，那么我们允许最多就能用4个P来供M使用）。所以M2只从能从全局队列取1个G（即G3）移动P2本地队列，然后完成从G0到G3的切换，运行G3。
场景8：偷取G的情况
全局队列已经没有G，那m就要执行work stealing(偷取)：从其他有G的P哪里偷取一半G过来，放到自己的P本地队列。P2从P1的本地队列尾部取一半的G，本例中一半则只有1个G8，放到P2的本地队列并执行。

场景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)，多余的没事做线程会让他们休眠。

场景10：G发生调用阻塞

自旋线程抢占G但是不抢占P
假定当前除了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绑定。

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

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

八、小结

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