Go Scheduler 的 GMP 模型

,Go 为了自身 goroutine 执行和调度的效率，自身在 runtime 中实现了一套 goroutine 的调度器，下面通过一段简单的代码展示一下 Go 应用程序在运行时的 goroutine，方便大家更好的理解。,上面这段代码的输出为：5。说明当前这个应用程序中存在 goroutine 的数量是 5，事实上也符合我们的预期。那么问题来了，这 5 个 goroutine 作为操作系统用户态的基本调度单元是无法直接占用操作系统的资源来执行的，必须经过内核级线程的分发，这是操作系统内部线程调度的基本模型，根据用户级线程和内核级线程的对应关系可以分为 1 对 1，N 对 1 以及 M 对 N 这三种模型，那么上述的 5 个 goroutine 在内核级线程上是怎么被分发的，这就是 Go语言的 goroutine 调度器决定的。,,整个 goroutine 调度器的实现基于 GMP 的三级模型来实现。,M 和 P 存在一一对应的绑定关系。大致的结构图如下所示：,,通常情况下，我们在代码中执行 go func(){}后，GMP 模型是如何工作的？通过一个详细的图来展示一下。,,整个 goroutine 调度器最重要的调度策略是：复用，避免频繁的资源创建和销毁，最大限度的提升系统的吞吐量和并发程度。这也是操作系统进行线程调度的终极目标。复用（reuse）也是很多「池化技术」的基础。,围绕着这一原则，goroutine 调度器在以下几个方面进行调度策略的优化。,另外，在 go 的 1.14 版本中，go 语言的技术团队尝试在调度器中添加了可抢占的技术[https://github.com/golang/go/issues/24543]。,在 go 语言的早期，goroutine 调度器的模型并不是 GMP，而是 GM。整个调度器维护一个全局的 G 的等待队列，所有的 M 从这个全局的队列中拉取 G 来执行，在 go1.1 中将这种模型直接干掉，取而代之的是现在的 GMP 模型，在 GM 模型的基础上增加 P 局部队列。官方之所有这么这么做，原因有二：