goroutine 调度

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 放入全局队列中