Go 调度器 GMP 调度场景
Go 调度器调度 11 种场景过程全解析
场景 1
G1 在运行中想要创建一个 G（G3），GMP 调度器会满足局部性，G1 创建的 G3 最好位于同一个 M 中。
G1 和 G3 可能会共享内存资源和会话是一致的。
G3 优先加入到 G1 所在的本地队列。
场景 2
G1 运行完成后 (函数：goexit)，M 上运行的 goroutine 切换为 G0（每一个 M 都有一个 G0），G0 负责调度时协程的切换（函数：schedule）。
这里的 G0 是 M 在创建时有一个结构体的指针指向 G0
由于本地队列中还有 G，所以从 P 的本地队列取 G2，从 G0 切换到 G2，并开始运行 G2(函数：execute)。实现了线程 M1 的复用。
场景 3
有这么一个场景，假设 P1 的本地队列最多只存 4 个 G，现在 G2 创建了 6 个 G，调度器该如何处理。
首先 G2 会创建 4 个 G 将 P1 的本地队列填满
接下来请看场景 4
场景 4
G2 在创建 G7 的时候，发现 P1 的本地队列已满，需要执行负载均衡(把 P1 中本地队列中前一半的 G，还有新创建 G转移到全局队列)，将 G3G4 打乱之后放在全局队列中，同时将新创建的 G7 也加入到全局队列中，这些 G 被转移到全局队列时，会被打乱顺序。所以 G3,G4,G7 被转移到全局队列。
全局队列中的 G 大概率会被不同核运行，打乱顺序能降低不同核同时修改同一缓存行的概率
场景 5
G2 创建 G8 时，P1 的本地队列未满，所以 G8 会被加入到 P1 的本地队列。
G8 加入到 P1 点本地队列的原因还是因为 P1 此时在与 M1 绑定，而 G2 此时是 M1 在执行。所以 G2 创建的新的 G 会优先放置到自己的 M 绑定的 P 上。
场景 6
规定：在创建 G 时，运行的 G 会尝试唤醒其他空闲的 P 和 M 组合去执行。
假定 G2 唤醒了 M2，M2 绑定了 P2，并运行 G0，但 P2 本地队列没有 G，M2 此时为自旋线程**（没有 G 但为运行状态的线程，不断寻找 G）**。M2 就会从先全局拿，如果全局队列中没有就去其他的本地队列去偷。
自旋线程：如果线程被销毁会消耗大量的硬件资源，与其让它销毁，不会让它寻找执行。自旋线程优先从全局队列中拿 G
场景 7
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 本地队列的负载均衡。
场景 8
假设 G2 一直在 M1 上运行，经过 2 轮后，M2 已经把 G7、G4 从全局队列获取到了 P2 的本地队列并完成运行，全局队列和 P2 的本地队列都空了，如场景 8 图的左半部分。
全局队列已经没有 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
假定当前除了 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 回收销毁)。