深刻Golang調度器之GMP模型

時間 2019-11-07

標籤深刻 golang 調度 gmp 模型欄目 Go 简体版

原文原文鏈接

前言

隨着服務器硬件迭代升級，配置也愈來愈高。爲充分利用服務器資源，併發編程也變的愈來愈重要。在開始以前，須要瞭解一下併發(concurrency)和並行(parallesim)的區別。linux

併發: 邏輯上具備處理多個同時性任務的能力。程序員

並行: 物理上同一時刻執行多個併發任務。編程

一般所說的併發編程，也就是說它容許多個任務同時執行，但實際上並不必定在同一時刻被執行。在單核處理器上，經過多線程共享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沒法運行的狀況發生。