golang的GPM调度

GPM模型

G：go中的协程
M: 系统线程，真正执行go代码的地方
P：调度上下文，保存本地G队列以及调度运行所需的资源，M必须绑定一个P 才能执行go代码在Go中，线程是运行goroutine的实体，调度器的功能是把可运行的goroutine分配到工作线程上

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

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

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

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

work stealing机制

hand off机制

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

在coroutine中要等待一个协程主动让出CPU才执行下一个协程，在Go中，一个goroutine最多占用CPU 10ms，防止其他goroutine被饿死，这就是goroutine不同于coroutine的一个地方。

从上图我们可以分析出几个结论：

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

Work Stealing 是 Go 调度器的负载均衡机制。
- 当某个 P 的本地运行队列为空时，它会优先检查全局队列，
- 如果仍然没有任务，就随机从其他 P 的本地队列偷取一半 Goroutine 执行，
- 从而提高多核 CPU 的利用率。
Netpoll 是 Go Runtime 对操作系统 IO 多路复用机制

解决的是网络 IO等待的问题，尽量避免 M 被阻塞。
- （Linux 上是 epoll，macOS 上是 kqueue，Windows 上是 IOCP）的封装。
- 对于网络 IO，Go 使用非阻塞 Socket，
- 当 Goroutine 执行 conn.Read() 且数据未就绪时，不会阻塞 M，
- 而是将 Goroutine 挂起，M 继续执行其他 Goroutine；
- 当 Netpoll 收到 IO 就绪事件后，
- 再将对应的 Goroutine 放回某个 P 的运行队列等待调度。
- 因此，Go 能够用少量线程支撑海量网络连接。
hand off 机制（P交接）
- 解决的是**阻塞系统调用（syscall）**导致 M 被卡住的问题
- M卡住了，然后M和P解绑