深刻Golang调度器之GMP模型

 

前言

随着服务器硬件迭代升级，配置也愈来愈高。为充分利用服务器资源，并发编程也变的愈来愈重要。在开始以前，须要了解一下并发(concurrency)和并行(parallesim)的区别。

并发:  逻辑上具备处理多个同时性任务的能力。

并行:   物理上同一时刻执行多个并发任务。

一般所说的并发编程，也就是说它容许多个任务同时执行，但实际上并不必定在同一时刻被执行。在单核处理器上，经过多线程共享CPU时间片串行执行(并发非并行)。而并行则依赖于多核处理器等物理资源，让多个任务能够实现并行执行(并发且并行)。

多线程或多进程是并行的基本条件，但单线程也能够用协程(coroutine)作到并发。简单将Goroutine概括为协程并不合适，由于它运行时会建立多个线程来执行并发任务，且任务单元可被调度到其它线程执行。这更像是多线程和协程的结合体，能最大限度提高执行效率，发挥多核处理器能力。

Go编写一个并发编程程序很简单，只须要在函数以前使用一个Go关键字就能够实现并发编程。

func main() {    go func(){        fmt.Println("Hello,World!")    }() }

Go调度器组成

Go语言虽然使用一个Go关键字便可实现并发编程，但Goroutine被调度到后端以后，具体的实现比较复杂。先看看调度器有哪几部分组成。

 一、G

G是Goroutine的缩写，至关于操做系统中的进程控制块，在这里就是Goroutine的控制结构，是对Goroutine的抽象。其中包括执行的函数指令及参数；G保存的任务对象；线程上下文切换，现场保护和现场恢复须要的寄存器(SP、IP)等信息。

Go不一样版本Goroutine默认栈大小不一样。

// Go1.11版本默认stack大小为2KB

_StackMin = 2048
 
// 建立一个g对象,而后放到g队列
// 等待被执行
func newproc1(fn *funcval, argp *uint8, narg int32, callergp *g, callerpc uintptr) {    _g_ := getg()    _g_.m.locks++    siz := narg    siz = (siz + 7) &^ 7    _p_ := _g_.m.p.ptr()    newg := gfget(_p_)    
    if newg == nil {        
       // 初始化g stack大小        newg = malg(_StackMin)        casgstatus(newg, _Gidle, _Gdead)        allgadd(newg)    }    
    // 如下省略}

二、M

M是一个线程或称为Machine，全部M是有线程栈的。若是不对该线程栈提供内存的话，系统会给该线程栈提供内存(不一样操做系统提供的线程栈大小不一样)。当指定了线程栈，则M.stack→G.stack，M的PC寄存器指向G提供的函数，而后去执行。

type m struct {    
    /*        1.  全部调用栈的Goroutine,这是一个比较特殊的Goroutine。        2.  普通的Goroutine栈是在Heap分配的可增加的stack,而g0的stack是M对应的线程栈。        3.  全部调度相关代码,会先切换到该Goroutine的栈再执行。    */    g0       *g    curg     *g         // M当前绑定的结构体G    // SP、PC寄存器用于现场保护和现场恢复    vdsoSP uintptr    vdsoPC uintptr    // 省略…}

三、P

P(Processor)是一个抽象的概念，并非真正的物理CPU。因此当P有任务时须要建立或者唤醒一个系统线程来执行它队列里的任务。因此P/M须要进行绑定，构成一个执行单元。

P决定了同时能够并发任务的数量，可经过GOMAXPROCS限制同时执行用户级任务的操做系统线程。能够经过runtime.GOMAXPROCS进行指定。在Go1.5以后GOMAXPROCS被默认设置可用的核数，而以前则默认为1。

// 自定义设置GOMAXPROCS数量
func GOMAXPROCS(n int) int {    
    /*        1.  GOMAXPROCS设置可执行的CPU的最大数量,同时返回以前的设置。        2.  若是n < 1,则不更改当前的值。    */    ret := int(gomaxprocs)    stopTheWorld("GOMAXPROCS")    
    // startTheWorld启动时,使用newprocs。    newprocs = int32(n)    startTheWorld()    
    return ret }

// 默认P被绑定到全部CPU核上
// P == cpu.cores

func getproccount() int32 {    
    const maxCPUs = 64 * 1024    var buf [maxCPUs / 8]byte    // 获取CPU Core    r := sched_getaffinity(0, unsafe.Sizeof(buf), &buf[0])    n := int32(0)    
    for _, v := range buf[:r] {        
       for v != 0 {            n += int32(v & 1)            v >>= 1        }    }    
    if n == 0 {       n = 1    }    
    return n }
// 一个进程默认被绑定在全部CPU核上,返回全部CPU core。
// 获取进程的CPU亲和性掩码系统调用
// rax 204                          ; 系统调用码
// system_call sys_sched_getaffinity; 系统调用名称
// rid  pid                         ; 进程号
// rsi unsigned int len             
// rdx unsigned long *user_mask_ptr
sys_linux_amd64.s: TEXT runtime·sched_getaffinity(SB),NOSPLIT,$0    MOVQ    pid+0(FP), DI    MOVQ    len+8(FP), SI    MOVQ    buf+16(FP), DX    MOVL    $SYS_sched_getaffinity, AX    SYSCALL    MOVL    AX, ret+24(FP)    RET

Go调度器调度过程

首先建立一个G对象，G对象保存到P本地队列或者是全局队列。P此时去唤醒一个M。P继续执行它的执行序。M寻找是否有空闲的P，若是有则将该G对象移动到它自己。接下来M执行一个调度循环(调用G对象->执行->清理线程→继续找新的Goroutine执行)。

M执行过程当中，随时会发生上下文切换。当发生上线文切换时，须要对执行现场进行保护，以便下次被调度执行时进行现场恢复。Go调度器M的栈保存在G对象上，只须要将M所须要的寄存器(SP、PC等)保存到G对象上就能够实现现场保护。当这些寄存器数据被保护起来，就随时能够作上下文切换了，在中断以前把现场保存起来。若是此时G任务尚未执行完，M能够将任务从新丢到P的任务队列，等待下一次被调度执行。当再次被调度执行时，M经过访问G的vdsoSP、vdsoPC寄存器进行现场恢复(从上次中断位置继续执行)。

 

一、P 队列
经过上图能够发现，P有两种队列：本地队列和全局队列。

• 本地队列： 当前P的队列，本地队列是Lock-Free，没有数据竞争问题，无需加锁处理，能够提高处理速度。

• 全局队列：全局队列为了保证多个P之间任务的平衡。全部M共享P全局队列，为保证数据竞争问题，须要加锁处理。相比本地队列处理速度要低于全局队列。

二、上线文切换

简单理解为当时的环境便可，环境能够包括当时程序状态以及变量状态。例如线程切换的时候在内核会发生上下文切换，这里的上下文就包括了当时寄存器的值，把寄存器的值保存起来，等下次该线程又获得cpu时间的时候再恢复寄存器的值，这样线程才能正确运行。

对于代码中某个值说，上下文是指这个值所在的局部(全局)做用域对象。相对于进程而言，上下文就是进程执行时的环境，具体来讲就是各个变量和数据，包括全部的寄存器变量、进程打开的文件、内存(堆栈)信息等。

三、线程清理
Goroutine被调度执行必须保证P/M进行绑定，因此线程清理只须要将P释放就能够实现线程的清理。何时P会释放，保证其它G能够被执行。P被释放主要有两种状况。

• 主动释放：最典型的例子是，当执行G任务时有系统调用，当发生系统调用时M会处于Block状态。调度器会设置一个超时时间，当超时时会将P释放。

• 被动释放：若是发生系统调用，有一个专门监控程序，进行扫描当前处于阻塞的P/M组合。当超过系统程序设置的超时时间，会自动将P资源抢走。去执行队列的其它G任务。

终于要来讲说Golang中最吸引人的goroutine了，这也是Golang可以横空出世的主要缘由。不一样于Python基于进程的并发模型，以及C++、Java等基于线程的并发模型。Golang采用轻量级的goroutine来实现并发，能够大大减小CPU的切换。如今已经有太多的文章来介绍goroutine的用法，在这里，咱们从源码的角度来看看其内部实现。

重申一下重点：goroutine中的三个实体

goroutine中最主要的是三个实体为GMP，其中：

G: 表明一个goroutine对象，每次go调用的时候，都会建立一个G对象，它包括栈、指令指针以及对于调用goroutines很重要的其它信息，好比阻塞它的任何channel，其主要数据结构：

type g struct { stack stack // 描述了真实的栈内存，包括上下界 m *m // 当前的m sched gobuf // goroutine切换时，用于保存g的上下文 param unsafe.Pointer // 用于传递参数，睡眠时其余goroutine能够设置param，唤醒时该goroutine能够获取 atomicstatus uint32 stackLock uint32 goid int64 // goroutine的ID waitsince int64 // g被阻塞的大致时间 lockedm *m // G被锁定只在这个m上运行 } 

其中最主要的固然是sched了，保存了goroutine的上下文。goroutine切换的时候不一样于线程有OS来负责这部分数据，而是由一个gobuf对象来保存，这样可以更加轻量级，再来看看gobuf的结构：

type gobuf struct { sp uintptr pc uintptr g guintptr ctxt unsafe.Pointer ret sys.Uintreg lr uintptr bp uintptr // for GOEXPERIMENT=framepointer } 

其实就是保存了当前的栈指针，计数器，固然还有g自身，这里记录自身g的指针是为了能快速的访问到goroutine中的信息。

M：表明一个线程，每次建立一个M的时候，都会有一个底层线程建立；全部的G任务，最终仍是在M上执行，其主要数据结构：

type m struct { g0 *g // 带有调度栈的goroutine gsignal *g // 处理信号的goroutine tls [6]uintptr // thread-local storage mstartfn func() curg *g // 当前运行的goroutine caughtsig guintptr p puintptr // 关联p和执行的go代码 nextp puintptr id int32 mallocing int32 // 状态 spinning bool // m是否out of work blocked bool // m是否被阻塞 inwb bool // m是否在执行写屏蔽 printlock int8 incgo bool // m在执行cgo吗 fastrand uint32 ncgocall uint64 // cgo调用的总数 ncgo int32 // 当前cgo调用的数目 park note alllink *m // 用于连接allm schedlink muintptr mcache *mcache // 当前m的内存缓存 lockedg *g // 锁定g在当前m上执行，而不会切换到其余m createstack [32]uintptr // thread建立的栈 } 

结构体M中有两个G是须要关注一下的，一个是curg，表明结构体M当前绑定的结构体G。另外一个是g0，是带有调度栈的goroutine，这是一个比较特殊的goroutine。普通的goroutine的栈是在堆上分配的可增加的栈，而g0的栈是M对应的线程的栈。全部调度相关的代码，会先切换到该goroutine的栈中再执行。也就是说线程的栈也是用的g实现，而不是使用的OS的。

P：表明一个处理器，每个运行的M都必须绑定一个P，就像线程必须在么一个CPU核上执行同样，由P来调度G在M上的运行，P的个数就是GOMAXPROCS（最大256），启动时固定的，通常不修改；M的个数和P的个数不必定同样多（会有休眠的M或者不须要太多的M）（最大10000）；每个P保存着本地G任务队列，也有一个全局G任务队列。P的数据结构：

type p struct { lock mutex id int32 status uint32 // 状态，能够为pidle/prunning/... link puintptr schedtick uint32 // 每调度一次加1 syscalltick uint32 // 每一次系统调用加1 sysmontick sysmontick m muintptr // 回链到关联的m mcache *mcache racectx uintptr goidcache uint64 // goroutine的ID的缓存 goidcacheend uint64 // 可运行的goroutine的队列 runqhead uint32 runqtail uint32 runq [256]guintptr runnext guintptr // 下一个运行的g sudogcache []*sudog sudogbuf [128]*sudog palloc persistentAlloc // per-P to avoid mutex pad [sys.CacheLineSize]byte 

其中P的状态有Pidle, Prunning, Psyscall, Pgcstop, Pdead；在其内部队列runqhead里面有可运行的goroutine，P优先从内部获取执行的g，这样可以提升效率。

除此以外，还有一个数据结构须要在这里说起，就是schedt，能够看作是一个全局的调度者：

type schedt struct { goidgen uint64 lastpoll uint64 lock mutex midle muintptr // idle状态的m nmidle int32 // idle状态的m个数 nmidlelocked int32 // lockde状态的m个数 mcount int32 // 建立的m的总数 maxmcount int32 // m容许的最大个数 ngsys uint32 // 系统中goroutine的数目，会自动更新 pidle puintptr // idle的p npidle uint32 nmspinning uint32 // 全局的可运行的g队列 runqhead guintptr runqtail guintptr runqsize int32 // dead的G的全局缓存 gflock mutex gfreeStack *g gfreeNoStack *g ngfree int32 // sudog的缓存中心 sudoglock mutex sudogcache *sudog } 

大多数须要的信息都已放在告终构体M、G和P中，schedt结构体只是一个壳。能够看到，其中有M的idle队列，P的idle队列，以及一个全局的就绪的G队列。schedt结构体中的Lock是很是必须的，若是M或P等作一些非局部的操做，它们通常须要先锁住调度器。

goroutine的运行过程

全部的goroutine都是由函数newproc来建立的，可是因为该函数不能调用分段栈，最后真正调用的是newproc1。在newproc1中主要进行以下动做：

func newproc1(fn *funcval, argp *uint8, narg int32, nret int32, callerpc uintptr) *g { newg = malg(_StackMin) casgstatus(newg, _Gidle, _Gdead) allgadd(newg) newg.sched.sp = sp newg.stktopsp = sp newg.sched.pc = funcPC(goexit) + sys.PCQuantum newg.sched.g = guintptr(unsafe.Pointer(newg)) gostartcallfn(&newg.sched, fn) newg.gopc = callerpc newg.startpc = fn.fn ...... } 

分配一个g的结构体
初始化这个结构体的一些域
将g挂在就绪队列
绑定g到一个m上

这个绑定只要m没有突破上限GOMAXPROCS,就拿一个m绑定一个g。若是m的waiting队列中有就从队列中拿,不然就要新建一个m,调用newm。

func newm(fn func(), _p_ *p) { mp := allocm(_p_, fn) mp.nextp.set(_p_) mp.sigmask = initSigmask execLock.rlock() newosproc(mp, unsafe.Pointer(mp.g0.stack.hi)) execLock.runlock() } 

该函数其实就是建立一个m，跟newproc有些类似，以前也说了m在底层就是一个线程的建立，也便是newosproc函数，在往下挖能够看到会根据不一样的OS来执行不一样的bsdthread_create函数，而底层就是调用的runtime.clone：

clone(cloneFlags,stk,unsafe.Pointer(mp),unsafe.Pointer(mp.g0),unsafe.Pointer(funcPC(mstart))) 

m建立好以后，线程的入口是mstart，最后调用的便是mstart1：

func mstart1() { _g_ := getg() gosave(&_g_.m.g0.sched) _g_.m.g0.sched.pc = ^uintptr(0) asminit() minit() if _g_.m == &m0 { initsig(false) } if fn := _g_.m.mstartfn; fn != nil { fn() } schedule() } 

里面最重要的就是schedule了，在schedule中的动做大致就是找到一个等待运行的g，而后而后搬到m上，设置其状态为Grunning,直接切换到g的上下文环境,恢复g的执行。

func schedule() { _g_ := getg() if _g_.m.lockedg != nil { stoplockedm() execute(_g_.m.lockedg, false) // Never returns. } } 

schedule的执行能够大致总结为：

schedule函数获取g => [必要时休眠] => [唤醒后继续获取] => execute函数执行g => 执行后返回到goexit => 从新执行schedule函数

简单来讲g所经历的几个主要的过程就是：Gwaiting->Grunnable->Grunning。经历了建立,到挂在就绪队列,到从就绪队列拿出并运行整个过程。

casgstatus(gp, _Gwaiting, _Grunnable) casgstatus(gp, _Grunnable, _Grunning) 

引入了struct M这层抽象。m就是这里的worker,但不是线程。处理系统调用中的m不会占用mcpu数量,只有干事的m才会对应到线程.当mcpu数量少于GOMAXPROCS时能够一直开新的线程干活.而goroutine的执行则是在m和g都知足以后经过schedule切换上下文进入的.

抢占式调度

当有不少goroutine须要执行的时候，是怎么调度的了，上面说的P尚未出场呢，在runtime.main中会建立一个额外m运行sysmon函数，抢占就是在sysmon中实现的。

sysmon会进入一个无限循环, 第一轮回休眠20us, 以后每次休眠时间倍增, 最终每一轮都会休眠10ms. sysmon中有netpool(获取fd事件), retake(抢占), forcegc(按时间强制执行gc), scavenge heap(释放自由列表中多余的项减小内存占用)等处理.

func sysmon() { lasttrace := int64(0) idle := 0 // how many cycles in succession we had not wokeup somebody delay := uint32(0) for { if idle == 0 { // start with 20us sleep... delay = 20 } else if idle > 50 { // start doubling the sleep after 1ms... delay *= 2 } if delay > 10*1000 { // up to 10ms delay = 10 * 1000 } usleep(delay) ...... } } 

里面的函数retake负责抢占：

func retake(now int64) uint32 { n := 0 for i := int32(0); i < gomaxprocs; i++ { _p_ := allp[i] if _p_ == nil { continue } pd := &_p_.sysmontick s := _p_.status if s == _Psyscall { // 若是p的syscall时间超过一个sysmon tick则抢占该p t := int64(_p_.syscalltick) if int64(pd.syscalltick) != t { pd.syscalltick = uint32(t) pd.syscallwhen = now continue } if runqempty(_p_) && atomic.Load(&sched.nmspinning)+atomic.Load(&sched.npidle) > 0 && pd.syscallwhen+10*1000*1000 > now { continue } incidlelocked(-1) if atomic.Cas(&_p_.status, s, _Pidle) { if trace.enabled { traceGoSysBlock(_p_) traceProcStop(_p_) } n++ _p_.syscalltick++ handoffp(_p_) } incidlelocked(1) } else if s == _Prunning { // 若是G运行时间过长，则抢占该G t := int64(_p_.schedtick) if int64(pd.schedtick) != t { pd.schedtick = uint32(t) pd.schedwhen = now continue } if pd.schedwhen+forcePreemptNS > now { continue } preemptone(_p_) } } return uint32(n) } 

枚举全部的P 若是P在系统调用中(_Psyscall), 且通过了一次sysmon循环(20us~10ms), 则抢占这个P， 调用handoffp解除M和P之间的关联， 若是P在运行中(_Prunning), 且通过了一次sysmon循环而且G运行时间超过forcePreemptNS(10ms), 则抢占这个P

并设置g.preempt = true，g.stackguard0 = stackPreempt。

为何设置了stackguard就能够实现抢占?

由于这个值用于检查当前栈空间是否足够, go函数的开头会比对这个值判断是否须要扩张栈。

newstack函数判断g.stackguard0等于stackPreempt, 就知道这是抢占触发的, 这时会再检查一遍是否要抢占。

抢占机制保证了不会有一个G长时间的运行致使其余G没法运行的状况发生。

总结

相比大多数并行设计模型，Go比较优点的设计就是P上下文这个概念的出现，若是只有G和M的对应关系，那么当G阻塞在IO上的时候，M是没有实际在工做的，这样形成了资源的浪费，没有了P，那么全部G的列表都放在全局，这样致使临界区太大，对多核调度形成极大影响。

而goroutine在使用上面的特色，感受既能够用来作密集的多核计算，又能够作高并发的IO应用，作IO应用的时候，写起来感受和对程序员最友好的同步阻塞同样，而实际上因为runtime的调度，底层是以同步非阻塞的方式在运行（即IO多路复用）。

因此说保护现场的抢占式调度和G被阻塞后传递给其余m调用的核心思想，使得goroutine的产生。

 

本文从宏观角度介绍了一下Go调度器的调度过程。Go调度器也是Go语言最精华的部分，但愿对你们有所帮助。