GMP模型

Go的调度为什么说是轻量的？
Go高度都发生了什么?
Go的网络和锁会不会阻塞线程?
什么时候会阻塞线程?
Go是怎样实现少量内核线程支撑大量Goroutine的并发运行?
为了最大限度利用计算资源，Go调度器是如何处理线程阻塞的场景?

GMP

G：goroutine 协程
P：processor 处理器
M：thread 内核线程
全局队列：存放等待运行的G
P的本地队列：
1.存放等待运行的G
2.数量限制（不超过256G）
3.优先将创建的G放在P的本地队列中，如果满了会放在全局队列中
P列表
1.程序启动时创建
2.最多有GOMAXPROCS个（可配置）
M列表(内核线程)：当前操作系统分配到当前Go程序的内核线程数
P和M的数量
1. P的数量:程序同一时刻同时执行的G数量
  1）环境变量$GOMAXPROCS
  2) 在程序中通过runtime.GOMAXPROCS设置
2. M数量(动态的)
  1）GO语言本身是限定M的最大量是10000(忽略)
  2）runtime/debug包中的SetMaxThreads函数来设置
  3) 如果有一个M阻塞，会创建一个新的M；如果有空闲M，就会回收或睡眠

设计策略

复用线程
利用并行
抢占
全局G队列

复用线程

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

work stealing机制(工作窃取)

M2线程空闲，它会窃取M1中P队列的G来执行

hand off机制(分手)

1.G1阻塞(chan阻塞等)

2.创建/唤醒一个thread(M3),将阻塞的M1和P分离,将P移置到M3线程中执行

利用并行

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

抢占

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

全局G队列

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

空闲的P会优先去其它P的本地队列窃取，其次去全局队列窃取，窃取前要加锁

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；

调度器生命周期

M0

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

G0

1.每次启动一个M，都会第一个创建的gourtine,就是G0
2.G0仅用于负责高度调度G的
3.G0不执行任何函数
4.每个M都会有一个自己的G0
5.在调度或系统调用时会使用M切换到G0，来调度
6.M0的G0存放在全局空间

GMP调试

go tool trace

package main

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

func main() {
	f, err := os.Create("trace.out")
	if err != nil {
		panic(err)
	}
	defer f.Close()

	err = trace.Start(f)
	if err != nil {
		panic(err)
	}
	defer trace.Stop()
	// Your program here
	fmt.Println("Hello GMP")
}

go run main.go
//打开trace.out文件
go tool trace trace.out 
2021/09/18 14:45:55 Parsing trace...
2021/09/18 14:45:55 Splitting trace...
2021/09/18 14:45:55 Opening browser. Trace viewer is listening on http://127.0.0.1:42452

GODEBUG

GODEBUG 变量可以控制运行时内的调试变量，参数以逗号分隔，格式为：name=val。本文着重点在调度器观察上，将会使用如下两个参数：
* schedtrace：设置 schedtrace=X 参数可以使运行时在每 X 毫秒发出一行调度器的摘要信息到标准 err 输出中。
* scheddetail：设置 schedtrace=X 和 scheddetail=1 可以使运行时在每 X 毫秒发出一次详细的多行信息，信息内容主要包括调度程序、处理器、OS 线程和 Goroutine 的状态

package main

import (
	"sync"
)

func main() {
	wg := sync.WaitGroup{}
	wg.Add(10)
	for i := 0; i < 10; i++ {
		go func(wg *sync.WaitGroup) {
			var counter int
			for i := 0; i < 1e10; i++ {
				counter++
			}
			wg.Done()
		}(&wg)
	}
	wg.Wait()
}

schedtrace

go build
GODEBUG=schedtrace=1000 ./trace
SCHED 0ms: gomaxprocs=12 idleprocs=9 threads=5 spinningthreads=1 idlethreads=0 runqueue=0 [1 0 0 0 0 0 0 0 0 0 0 0]
SCHED 1001ms: gomaxprocs=12 idleprocs=2 threads=12 spinningthreads=0 idlethreads=1 runqueue=0 [0 0 0 0 0 0 0 0 0 0 0 0]
SCHED 2009ms: gomaxprocs=12 idleprocs=2 threads=12 spinningthreads=0 idlethreads=1 runqueue=0 [0 0 0 0 0 0 0 0 0 0 0 0]
SCHED 3018ms: gomaxprocs=12 idleprocs=2 threads=12 spinningthreads=0 idlethreads=1 runqueue=0 [0 0 0 0 0 0 0 0 0 0 0 0]
SCHED 4025ms: gomaxprocs=12 idleprocs=5 threads=12 spinningthreads=0 idlethreads=4 runqueue=0 [0 0 0 0 0 0 0 0 0 0 0 0]

sched：每一行都代表调度器的调试信息，后面提示的毫秒数表示启动到现在的运行时间，输出的时间间隔受 schedtrace 的值影响。
gomaxprocs：当前的 CPU 核心数（GOMAXPROCS 的当前值）。
idleprocs：空闲的处理器数量，后面的数字表示当前的空闲数量。
threads：OS 线程数量，后面的数字表示当前正在运行的线程数量。
spinningthreads：自旋状态的 OS 线程数量。(不断寻找G)
idlethreads：空闲的线程数量。
runqueue：全局队列中的 Goroutine 数量，而后面的 [1 0 0 0 0 0 0 0 0 0 0 0]则分别代表这 12 个 P 的本地队列正在运行的 Goroutine 数量。