G-P-M 模型

G-P-M 模型概述

每个OS线程都有一个固定大小的内存块(通常会是2MB)来作栈，这个栈会用来存储当前正在被调用或挂起(指在调用其它函数时)的函数的内部变量。这个固定大小的栈同时很大又很小。由于2MB的栈对于一个小小的goroutine来讲是很大的内存浪费，而对于一些复杂的任务（如深度嵌套的递归）来讲又显得过小。所以，Go语言作了它本身的『线程』。

在Go语言中，每个goroutine是一个独立的执行单元，相较于每一个OS线程固定分配2M内存的模式，goroutine的栈采起了动态扩容方式， 初始时仅为2KB，随着任务执行按需增加，最大可达1GB（64位机器最大是1G，32位机器最大是256M），且彻底由golang本身的调度器 Go Scheduler 来调度。此外，GC还会周期性地将再也不使用的内存回收，收缩栈空间。 所以，Go程序能够同时并发成千上万个goroutine是得益于它强劲的调度器和高效的内存模型。Go的创造者大概对goroutine的定位就是屠龙刀，由于他们不只让goroutine做为golang并发编程的最核心组件（开发者的程序都是基于goroutine运行的）并且golang中的许多标准库的实现也处处能见到goroutine的身影，好比net/http这个包，甚至语言自己的组件runtime运行时和GC垃圾回收器都是运行在goroutine上的，做者对goroutine的厚望可见一斑。

任何用户线程最终确定都是要交由OS线程来执行的，goroutine（称为G）也不例外，可是G并不直接绑定OS线程运行，而是由Goroutine Scheduler中的 P - Logical Processor （逻辑处理器）来做为二者的『中介』，P能够看做是一个抽象的资源或者一个上下文，一个P绑定一个OS线程，在golang的实现里把OS线程抽象成一个数据结构：M，G其实是由M经过P来进行调度运行的，可是在G的层面来看，P提供了G运行所需的一切资源和环境，所以在G看来P就是运行它的 “CPU”，由 G、P、M 这三种由Go抽象出来的实现，最终造成了Go调度器的基本结构：

• G: 表示Goroutine，每一个Goroutine对应一个G结构体，G存储Goroutine的运行堆栈、状态以及任务函数，可重用。G并不是执行体，每一个G须要绑定到P才能被调度执行。
• P: Processor，表示逻辑处理器， 对G来讲，P至关于CPU核，G只有绑定到P(在P的local runq中)才能被调度。对M来讲，P提供了相关的执行环境(Context)，如内存分配状态(mcache)，任务队列(G)等，P的数量决定了系统内最大可并行的G的数量（前提：物理CPU核数 >= P的数量），P的数量由用户设置的GOMAXPROCS决定，可是不论GOMAXPROCS设置为多大，P的数量最大为256。
• M: Machine，OS线程抽象，表明着真正执行计算的资源，在绑定有效的P后，进入schedule循环；而schedule循环的机制大体是从Global队列、P的Local队列以及wait队列中获取G，切换到G的执行栈上并执行G的函数，调用goexit作清理工做并回到M，如此反复。M并不保留G状态，这是G能够跨M调度的基础，M的数量是不定的，由Go Runtime调整，为了防止建立过多OS线程致使系统调度不过来，目前默认最大限制为10000个。

关于P，咱们须要再絮叨几句，在Go 1.0发布的时候，它的调度器其实G-M模型，也就是没有P的，调度过程全由G和M完成，这个模型暴露出一些问题：

• 单一全局互斥锁(Sched.Lock)和集中状态存储的存在致使全部goroutine相关操做，好比：建立、从新调度等都要上锁；
• goroutine传递问题：M常常在M之间传递『可运行』的goroutine，这致使调度延迟增大以及额外的性能损耗；
• 每一个M作内存缓存，致使内存占用太高，数据局部性较差；
• 因为syscall调用而造成的剧烈的worker thread阻塞和解除阻塞，致使额外的性能损耗。

这些问题实在太扎眼了，致使Go1.0虽然号称原生支持并发，却在并发性能上一直饱受诟病，而后，Go语言委员会中一个核心开发大佬看不下了，亲自下场从新设计和实现了Go调度器（在原有的G-M模型中引入了P）而且实现了一个叫作 work-stealing 的调度算法：

• 每一个P维护一个G的本地队列；
• 当一个G被建立出来，或者变为可执行状态时，就把他放到P的可执行队列中；
• 当一个G在M里执行结束后，P会从队列中把该G取出；若是此时P的队列为空，即没有其余G能够执行， M就随机选择另一个P，从其可执行的G队列中取走一半。

该算法避免了在goroutine调度时使用全局锁。

至此，Go调度器的基本模型确立：

G-P-M 模型调度

Go调度器工做时会维护两种用来保存G的任务队列：一种是一个Global任务队列，一种是每一个P维护的Local任务队列。

当经过go关键字建立一个新的goroutine的时候，它会优先被放入P的本地队列。为了运行goroutine，M须要持有（绑定）一个P，接着M会启动一个OS线程，循环从P的本地队列里取出一个goroutine并执行。固然还有上文说起的 work-stealing调度算法：当M执行完了当前P的Local队列里的全部G后，P也不会就这么在那躺尸啥都不干，它会先尝试从Global队列寻找G来执行，若是Global队列为空，它会随机挑选另一个P，从它的队列里中拿走一半的G到本身的队列中执行。

若是一切正常，调度器会以上述的那种方式顺畅地运行，但这个世界没这么美好，总有意外发生，如下分析goroutine在两种例外状况下的行为。

Go runtime会在下面的goroutine被阻塞的状况下运行另一个goroutine：

• blocking syscall (for example opening a file)
• network input
• channel operations
• primitives in the sync package

这四种场景又可归类为两种类型：

用户态阻塞/唤醒

当goroutine由于channel操做或者network I/O而阻塞时（实际上golang已经用netpoller实现了goroutine网络I/O阻塞不会致使M被阻塞，仅阻塞G，这里仅仅是举个栗子），对应的G会被放置到某个wait队列(如channel的waitq)，该G的状态由_Gruning变为_Gwaitting，而M会跳过该G尝试获取并执行下一个G，若是此时没有runnable的G供M运行，那么M将解绑P，并进入sleep状态；当阻塞的G被另外一端的G2唤醒时（好比channel的可读/写通知），G被标记为runnable，尝试加入G2所在P的runnext，而后再是P的Local队列和Global队列。

系统调用阻塞

当G被阻塞在某个系统调用上时，此时G会阻塞在_Gsyscall状态，M也处于 block on syscall 状态，此时的M可被抢占调度：执行该G的M会与P解绑，而P则尝试与其它idle的M绑定，继续执行其它G。若是没有其它idle的M，但P的Local队列中仍然有G须要执行，则建立一个新的M；当系统调用完成后，G会从新尝试获取一个idle的P进入它的Local队列恢复执行，若是没有idle的P，G会被标记为runnable加入到Global队列。

以上就是从宏观的角度对Goroutine和它的调度器进行的一些概要性的介绍，固然，Go的调度中更复杂的抢占式调度、阻塞调度的更多细节，你们能够自行去找相关资料深刻理解，本文只讲到Go调度器的基本调度过程，为后面本身实现一个Goroutine Pool提供理论基础，这里便再也不继续深刻上述说的那几个调度了，事实上若是要彻底讲清楚Go调度器，一篇文章的篇幅也实在是捉襟见肘，因此想了解更多细节的同窗能够去看看Go调度器 G-P-M 模型的设计者 Dmitry Vyukov 写的该模型的设计文档《 Go Preemptive Scheduler Design》以及直接去看源码，G-P-M模型的定义放在src/runtime/runtime2.go里面，而调度过程则放在了src/runtime/proc.go里。

 

REFERENCE：

 

Goroutine并发调度模型深度解析&手撸一个协程池