Go 的调度器模型一开始是一个简单的模型：G-M 模型，后来因为性能的问题被弃用了，现在的调度器模型是 G-P-M 模型

G-M 模型

我们用 G 表示 goroutine，M 表示 thread 线程，下图是 G-M 模型的的实现：

M 想要执行、放回 G 都需要先申请锁，然后从全局队列获取/放回 G。因为 M 有多个，所以在访问全局队列的时候需要锁来完成互斥/同步。

G-M 模型的缺点：

1. 频繁的申请锁会造成激烈的竞争
2. G 在不同 M 直接的切换会造成延迟和额外的系统负载。比如 M 上运行的 G 创建了 G’，G’ 就需要给其他 M 执行，此时会造成很差的 “局部性”，因为 G’ 与 G 是相关的，所以最好和 G 在同一个 M 上运行
3. 系统调用(CPU 在 M 之间的切换)导致频繁的线程阻塞和取消阻塞增加了的系统开销

G-M-P 模型

G-M-P 引进了 P(processor 处理器)，P 包含了运行 goroutine 的资源，它有一个本地队列，本地队列里存放了可运行的 G。

下面是 G-M-P 模型原理：

全局队列：存放可运行的 G

本地队列：也是存放可运行的 G，不过有数量限制，最多为 256 个，新创建的 G 优先放入本地队列中，如果本地队列满了，则会将队列中一半的 G 放入全局队列中

P：所有的 P 都在程序启动时创建，并保存在数组中，最多可创建 GOMAXPROCS 个。GOMAXPROCS 可通过 GO 环境变量和 runtime 包的 GOMAXPROCS 函数设置

M：M 要运行 G 就要选择与一个 P 绑定，然后从 P 的本地队列中拿走 G 并运行，运行完后再拿走下一个 G，如此往复。如果 P 的本地队列为空，则 M 可能会从全局队列中拿一批 G 放入 P 的本地队列，也可能会从其他 P 的本地队列中偷一半放到与自己 P 绑定的本地队列中

goroutine 调度器是通过 M 与 OS 调度器结合起来的，每个 M 代表了一个内核线程，OS 调度器负责吧内核线程分配到 CPU 的核上运行。

P 和 M 何时创建

P：当确认了最多可创建的 P 个数 n 之后，运行时系统会根据这个值创建 n 个 P

M：没有足够的 M 来关联 P 运行 P 的本地队列中的 可运行的 G 时。比如现在所有的 M 都在运行，而还有 P 的本地队列中有空闲的 G，P 会去找空闲的 M，如果找不到就会创建一个新的 M

调度器设计策略

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

1. work stealing 机制

   当线程绑定的 P 本地队列中为空的时候，可以从其他已绑定的 P 中偷一半的 G 到自己绑定的 P 的本地队列中来运行，而不是销毁

2. hand off 机制

   当线程因为 G 进行系统调用而阻塞时，线程会释放绑定的 P(线程与 G 一起阻塞)，转移给其他空闲的线程处理

• 利用并行

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

• 抢占式调度

  一个 goroutine 最多占用 CPU 10 ms，防止其他 goroutine 饿死。

• 全局队列

  当线程在进行 work stealing 工作的时候，如果从其他 P 中偷不到 G ，就会从全局队列中获取 G

参考

也谈 goroutine 调度器

Golang 调度器 GMP 原理与调度全分析