一、Go 调度器的作用
提到“调度”，咱们首先想到的就是操作系统对过程、线程的调度。操作系统调度器会将零碎中的多个线程依照肯定算法调度到物理 CPU 下来运行。
这种传统反对并发的形式有诸多有余：
一个 thread 的代价曾经比过程小了很多了，但咱们仍然不能大量创立 thread，因为除了每个 thread 占用的资源不小之外，操作系统调度切换 thread 的代价也不小；
Go 采纳了用户层轻量级 thread 的概念来解决这些问题，Go 将之称为”goroutine“。goroutine 占用的资源十分小，每个内存占用在 2k 左右，goroutine 调度的切换也不必陷入操作系统内核层实现，代价很低。因而，一个 Go 程序中能够创立成千上万个并发的 goroutine。
一个 Go 程序对于操作系统来说只是一个用户层程序，它的眼中只有 thread，它甚至不晓得 Goroutine 的存在。将这些 goroutines 依照肯定算法放到“CPU”上执行的程序就称为 goroutine 调度器或 goroutine scheduler。在操作系统层面，Thread 竞争的“CPU”资源是实在的物理 CPU，但在 Go 程序层面，各个 Goroutine 要竞争的”CPU”资源是操作系统线程。
说到这里 goroutine scheduler 的工作就明确了：
goroutine 调度器通过应用与 CPU 数量相等的线程缩小线程频繁切换的内存开销，同时在每一个线程上执行额定开销更低的 Goroutine 来升高操作系统和硬件的负载。
二、Go 调度器模型与演化过程
1、G- M 模型
2012 年 3 月 28 日，Go 1.0 正式公布。在这个版本中，每个 goroutine 对应于 runtime 中的一个形象构造：G，而 os thread 则被形象为一个构造：M(machine)。
M 想要执行、放回 G 都必须拜访全局 G 队列，并且 M 有多个，即多线程拜访同一资源须要加锁进行保障互斥 / 同步，所以全局 G 队列是有互斥锁进行爱护的。
这个构造尽管简略，然而却存在着许多问题：
1、所有 goroutine 相干操作，比方：创立、从新调度等都要上锁；
2、M 转移 G 会造成提早和额定的零碎负载。比方当 G 中蕴含创立新协程的时候，M 创立了 G1，为了继续执行 G，须要把 G1 交给 M1 执行，也造成了很差的局部性，因为 G1 和 G 是相干的，最好放在 M 上执行，而不是其余 M1。
3、零碎调用 (CPU 在 M 之间的切换) 导致频繁的线程阻塞和勾销阻塞操作减少了零碎开销。
2、G-P- M 模型
在 Go 1.1 中实现了 G -P- M 调度模型和 work stealing 算法，这个模型始终沿用至今：
在新调度器中，除了 M(thread)和 G(goroutine)，又引进了 P(Processor)。P 是一个“逻辑 Proccessor”，每个 G 要想真正运行起来，首先须要被调配一个 P（进入到 P 的本地队列中），对于 G 来说，P 就是运行它的“CPU”，能够说：G 的眼里只有 P。但从 Go scheduler 视角来看，真正的“CPU”是 M，只有将 P 和 M 绑定能力让 P 的 runq 中 G 得以实在运行起来。
这里有一幅图能够形象的阐明它们的关系：
地鼠用小车运着一堆待加工的砖。M 就可以看作图中的地鼠，P 就是小车，G 就是小车里装的砖。
3、抢占式调度
G-P- M 模型的实现算是 Go scheduler 的一大提高，但 Scheduler 依然有一个头疼的问题，那就是不反对抢占式调度，导致一旦某个 G 中呈现死循环或永恒循环的代码逻辑，那么 G 将永恒占用调配给它的 P 和 M，位于同一个 P 中的其余 G 将得不到调度，呈现“饿死”的状况。更为严重的是，当只有一个 P 时 (GOMAXPROCS=1) 时，整个 Go 程序中的其余 G 都将“饿死”。
这个抢占式调度的原理则是在每个函数或办法的入口，加上一段额定的代码，让 runtime 有机会查看是否须要执行抢占调度。
三、G-P- M 模型的深刻了解
1、基本概念
1、全局队列（Global Queue）：寄存期待运行的 G。2、P 的本地队列：同全局队列相似，寄存的也是期待运行的 G，存的数量无限，不超过 256 个。新建 G'时，G' 优先退出到 P 的本地队列，如果队列满了，则会把本地队列中一半的 G 挪动到全局队列。3、P：P 的数量决定了零碎内最大可并行的 G 的数量，P 的最大作用还是其领有的各种 G 对象队列、链表、一些 cache 和状态。所有的 P 都在程序启动时创立，并保留在数组中，默认等于 CUP 核数，最多有 GOMAXPROCS(可配置)个。4、M：线程想运行工作就得获取 P，从 P 的本地队列获取 G。P 队列为空时，M 也会尝试从全局队列拿一批 G 放到 P 的本地队列，或从其余 P 的本地队列偷一半放到本人 P 的本地队列。M 运行 G，G 执行之后，M 会从 P 获取下一个 G，一直反复上来。M 的创立机会：按需创立，没有足够的 M 来关联 P 并运行其中的可运行的 G 就会去创立新的 M。2、调度器的设计策略
2.1、复用线程
防止频繁的创立、销毁线程，而是对线程的复用。
1）work stealing 机制
当本线程无可运行的 G 时，尝试从其余线程绑定的 P 偷取 G，而不是销毁线程。
2）hand off 机制
当本线程因为 G 进行零碎调用阻塞时，线程开释绑定的 P，把 P 转移给其余闲暇的线程执行。
2.2、利用并行
GOMAXPROCS 设置 P 的数量，最多有 GOMAXPROCS 个线程散布在多个 CPU 上同时运行。
2.3、抢占
Go 程序启动时，运行时会去启动一个名为 sysmon 的 M，
会定时向长时间（>=10MS）运行的 G 工作收回抢占调度，避免其余 goroutine 被饿死。
2.4、全局 G 队列
在新的调度器中仍然有全局 G 队列，但性能曾经被弱化了，当 M 执行 work stealing 从其余 P 偷不到 G 时，它能够从全局 G 队列获取 G。
3、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；
6、当 M 零碎调用完结时候，这个 G 会尝试获取一个闲暇的 P 执行，并放入到这个 P 的本地队列。如果获取不到 P，那么这个线程 M 变成休眠状态，退出到闲暇线程中，而后这个 G 会被放入全局队列中。
4、调度器的生命周期
非凡的 M0 和 G0
M0
M0 是启动程序后的编号为 0 的主线程，这个 M 对应的实例会在全局变量 runtime.m0 中，不须要在 heap 上调配，M0 负责执行初始化操作和启动第一个 G，在之后 M0 就和其余的 M 一样了。
G0
G0 是每次启动一个 M 都会第一个创立的 gourtine，G0 仅用于负责调度的 G，G0 不指向任何可执行的函数, 每个 M 都会有一个本人的 G0。在调度或零碎调用时会应用 G0 的栈空间, 全局变量的 G0 是 M0 的 G0。
运行流程如图所示：
- runtime 创立最后的线程 m0 和 goroutine g0，并把 2 者关联。
- 调度器初始化：初始化 m0、栈、垃圾回收，以及创立和初始化由 GOMAXPROCS 个 P 形成的 P 列表。
- 示例代码中的 main 函数是 main.main，runtime 中也有 1 个 main 函数——runtime.main，代码通过编译后，runtime.main 会调用 main.main，程序启动时会为 runtime.main 创立 goroutine，称它为 main goroutine 吧，而后把 main goroutine 退出到 P 的本地队列。
- 启动 m0，m0 曾经绑定了 P，会从 P 的本地队列获取 G，获取到 main goroutine。
- G 领有栈，M 依据 G 中的栈信息和调度信息设置运行环境
- M 运行 G
- G 退出，再次回到 M 获取可运行的 G，这样反复上来，直到 main.main 退出，runtime.main 执行 Defer 和 Panic 解决，或调用 runtime.exit 退出程序。
调度器的生命周期简直占满了一个 Go 程序的毕生，runtime.main 的 goroutine 执行之前都是为调度器做筹备工作，runtime.main 的 goroutine 运行，才是调度器的真正开始，直到 runtime.main 完结而完结。
参考资料：
也谈 goroutine 调度器
Golang 的协程调度器原理及 GMP 设计思维
Goroutine 调度器