go中的關鍵字-go(上)

1. goroutine的使用

　　在Go語言中，表達式go f(x, y, z)會啓動一個新的goroutine運行函數f(x, y, z)，建立一個併發任務單元。即go關鍵字能夠用來開啓一個goroutine(協程))進行任務處理。

　　建立單個goroutine

 1 package main
 2 
 3 import (
 4     "fmt"
 5 )
 6 
 7 func HelloWorld() {
 8     fmt.Println("Hello goroutine")
 9 }
10 
11 func main() {
12     go HelloWorld()      // 開啓一個新的併發運行
       time.Sleep(1*time.Second)
13     fmt.Println("後輸出消息！")
14 }

　　輸出

1 Hello goroutine
2 後輸出消息！

　　這裏的sleep是必須的，不然你可能看不到goroutine裏頭的輸出,或者裏面的消息後輸出。由於當main函數返回時，全部的gourutine都是暴力終結的，而後程序退出。

　　建立多個goroutine時

 1 package main
 2 
 3 import (
 4     "fmt"
 5     "time"
 6 )
 7 
 8 func DelayPrint() {
 9     for i := 1; i <= 3; i++ {
10         time.Sleep(500 * time.Millisecond)
11         fmt.Println(i)
12     }
13 }
14 
15 func HelloWorld() {
16     fmt.Println("Hello goroutine")
17 }
18 
19 func main() {
20     go DelayPrint()     // 第一個goroutine
21     go HelloWorld()     // 第二個goroutine
22     time.Sleep(10*time.Second)
23     fmt.Println("main func")
24 }

　　輸出

1 Hello  goroutine
2 1
3 2
4 3
5 4
6 
7 main func

　　當去掉 DelayPrint() 函數裏的sleep以後，輸出爲：

1 1
2 2
3 3
4 4
5 Hello goroutine
6 main function

　　說明第二個goroutine不會由於第一個而堵塞或者等待。事實是當程序執行go FUNC()的時候，只是簡單的調用而後就當即返回了，並不關心函數裏頭髮生的故事情節，因此不一樣的goroutine直接不影響，main會繼續按順序執行語句。

goroutine阻塞

　　場景一：

1 package main
2 
3 func main() {
4     ch := make(chan int)
5     <- ch // 阻塞main goroutine, 通道被鎖
6 }

　　運行程序會報錯：

1 fatal error: all goroutines are asleep - deadlock!
2 
3 goroutine 1 [chan receive]:
4 main.main()

　　場景二

 1 package main
 2 
 3 func main() {
 4     ch1, ch2 := make(chan int), make(chan int)
 5 
 6     go func() {
 7         ch1 <- 1 // ch1通道的數據沒有被其餘goroutine讀取走，堵塞當前goroutine
 8         ch2 <- 0
 9     }()
10 
11     <- ch2 // ch2 等待數據的寫
12 }

　　非緩衝通道上若是隻有數據流入，而沒有流出，或者只流出無流入，都會引發阻塞。 goroutine的非緩衝通道里頭必定要一進一出，成對出現。 上面例子，一：流出無流入；二：流入無流出。

　　處理方式：

　　1. 讀取通道數據

 1 package main
 2 
 3 func main() {
 4     ch1, ch2 := make(chan int), make(chan int)
 5 
 6     go func() {
 7         ch1 <- 1 // ch1通道的數據沒有被其餘goroutine讀取走，堵塞當前goroutine
 8         ch2 <- 0
 9     }()
10 
11     <- ch1 // 取走即是
12     <- ch2 // chb 等待數據的寫
13 }

　　2. 建立緩衝通道

 1 package main
 2 
 3 func main() {
 4     ch1, ch2 := make(chan int, 3), make(chan int)
 5 
 6     go func() {
 7         ch1 <- 1 // cha通道的數據沒有被其餘goroutine讀取走，堵塞當前goroutine
 8         ch2 <- 0
 9     }()
10 
11     <- ch2 // ch2 等待數據的寫
12 }

2. goroutine調度器相關結構

　　goroutine的調度涉及到幾個重要的數據結構，咱們先逐一介紹和分析這幾個數據結構。這些數據結構分別是結構體G，結構體M，結構體P，以及Sched結構體。前三個的定義在文件runtime/runtime.h中，而Sched的定義在runtime/proc.c中。Go語言的調度相關實現也是在文件proc.c中。

2.1 結構體G

　　g是goroutine的縮寫，是goroutine的控制結構，是對goroutine的抽象。看下它內部主要的一些結構：

 1 type g struct {
 2    //堆棧參數。
 3      //堆棧描述了實際的堆棧內存：[stack.lo，stack.hi）。
 4      // stackguard0是在Go堆棧增加序言中比較的堆棧指針。
 5      //一般是stack.lo + StackGuard，可是能夠經過StackPreempt觸發搶佔。
 6      // stackguard1是在C堆棧增加序言中比較的堆棧指針。
 7      //它是g0和gsignal堆棧上的stack.lo + StackGuard。
 8      //在其餘goroutine堆棧上爲〜0，以觸發對morestackc的調用（並崩潰）。

 9   //當前g使用的棧空間，stack結構包括 [lo, hi]兩個成員
10     stack       stack   // offset known to runtime/cgo

11   // 用於檢測是否須要進行棧擴張，go代碼使用
12     stackguard0 uintptr // offset known to liblink

13   // 用於檢測是否須要進行棧擴展，原生代碼使用的
14     stackguard1 uintptr // offset known to liblink

15   // 當前g所綁定的m
16     m              *m      // current m; offset known to arm liblink

17   // 當前g的調度數據，當goroutine切換時，保存當前g的上下文，用於恢復
18     sched          gobuf

19     // goroutine運行的函數
20     fnstart        *FuncVal        
21     // g當前的狀態
22     atomicstatus   uint32
23   // 當前g的id
24     goid           int64

25      // 狀態Gidle,Grunnable,Grunning,Gsyscall,Gwaiting,Gdead
26     status   int16

27   // 下一個g的地址，經過guintptr結構體的ptr set函數能夠設置和獲取下一個g，經過這個字段和sched.gfreeStack sched.gfreeNoStack 能夠把 free g串成一個鏈表
28     schedlink      guintptr

29   // 判斷g是否容許被搶佔
30     preempt        bool       // preemption signal, duplicates stackguard0 = stackpreempt

31     // g是否要求要回到這個M執行, 有的時候g中斷了恢復會要求使用原來的M執行
32     lockedm        muintptr

33     // 用於傳遞參數，睡眠時其它goroutine設置param，喚醒時此goroutine能夠獲取
       param  *void

34    // 建立這個goroutine的go表達式的pc
35    uintptr    gopc
36 }

　　其中包含了棧信息stackbase和stackguard，有運行的函數信息fnstart。這些就足夠成爲一個可執行的單元了，只要獲得CPU就能夠運行。goroutine切換時，上下文信息保存在結構體的sched域中。goroutine切換時，上下文信息保存在結構體的sched域中。goroutine是輕量級的線程或者稱爲協程，切換時並沒必要陷入到操做系統內核中，很輕量級。

　　結構體G中的Gobuf，其實只保存了當前棧指針，程序計數器，以及goroutine自身。

1 struct Gobuf
2 {
3     //這些字段的偏移是libmach已知的（硬編碼的）。
4     sp   uintper;
5     pc   *byte;
6     g    *G;
7     ...
8 };

　　記錄g是爲了恢復當前goroutine的結構體G指針，運行時庫中使用了一個常駐的寄存器extern register G* g，這是當前goroutine的結構體G的指針。這種結構是爲了快速地訪問goroutine中的信息，好比，Go的棧的實現並無使用%ebp寄存器，不過這能夠經過g->stackbase快速獲得。"extern register"是由6c，8c等實現的一個特殊的存儲，在ARM上它是實際的寄存器。在linux系統中，對g和m使用的分別是0(GS)和4(GS)。連接器還會根據特定操做系統改變編譯器的輸出，每一個連接到Go程序的C文件都必須包含runtime.h頭文件，這樣C編譯器知道避免使用專用的寄存器。

2.2 結構體P

　　P是Processor的縮寫。結構體P的加入是爲了提升Go程序的併發度，實現更好的調度。M表明OS線程。P表明Go代碼執行時須要的資源。

 1 type p struct {
 2    lock mutex
 3 
 4    id          int32
 5    // p的狀態，稍後介紹
 6    status      uint32 // one of pidle/prunning/...
 7 
 8    // 下一個p的地址，可參考 g.schedlink
 9    link        puintptr
10    // p所關聯的m
11    m           muintptr   // back-link to associated m (nil if idle)
12 
13    // 內存分配的時候用的，p所屬的m的mcache用的也是這個
14    mcache      *mcache
15   
16    // Cache of goroutine ids, amortizes accesses to runtime·sched.goidgen.
17    // 從sched中獲取並緩存的id，避免每次分配goid都從sched分配
18      goidcache    uint64
19      goidcacheend uint64
20 
21    // Queue of runnable goroutines. Accessed without lock.
22    // p 本地的runnbale的goroutine造成的隊列
23    runqhead uint32
24    runqtail uint32
25    runq     [256]guintptr
26 
27    // runnext，若是不是nil，則是已準備好運行的G
28    //當前的G，而且應該在下一個而不是其中運行
29    // runq，若是運行G的時間還剩時間
30    //切片。它將繼承當前時間剩餘的時間
31    //切片。若是一組goroutine鎖定在
32    //交流等待模式，該計劃將其設置爲
33    //單位並消除（可能很大）調度
34    //不然會因爲添加就緒商品而引發的延遲
35    // goroutines到運行隊列的末尾。
36 
37    // 下一個執行的g，若是是nil，則從隊列中獲取下一個執行的g
38    runnext guintptr
39 
40    // Available G's (status == Gdead)
41    // 狀態爲 Gdead的g的列表，能夠進行復用
42    gfree    *g
43    gfreecnt int32
44 }

　　跟G不一樣的是，P不存在waiting狀態。MCache被移到了P中，可是在結構體M中也還保留着。在P中有一個Grunnable的goroutine隊列，這是一個P的局部隊列。當P執行Go代碼時，它會優先從本身的這個局部隊列中取，這時能夠不用加鎖，提升了併發度。若是發現這個隊列空了，則去其它P的隊列中拿一半過來，這樣實現工做流竊取的調度。這種狀況下是須要給調用器加鎖的。

2.3 結構體M

　　M是machine的縮寫，是對機器的抽象，每一個m都是對應到一條操做系統的物理線程。

 1 type m struct {
 2      // g0是用於調度和執行系統調用的特殊g
 3    g0      *g             // goroutine with scheduling stack
 4      // m當前運行的g
 5    curg    *g             // current running goroutine
 6    // 當前擁有的p
 7    p        puintptr      // attached p for executing go code (nil if not executing go code)

 8    // 線程的 local storage
 9    tls      [6]uintptr    // thread-local storage
10    // 喚醒m時，m會擁有這個p
11    nextp         puintptr
12    id            int64
13    // 若是 !="", 繼續運行curg
14    preemptoff    string   // if != "", keep curg running on this m

15    // 自旋狀態，用於判斷m是否工做已結束，並尋找g進行工做
16    spinning      bool     // m is out of work and is actively looking for work

17    // 用於判斷m是否進行休眠狀態
18    blocked       bool     // m is blocked on a note
19    // m休眠和喚醒經過這個，note裏面有一個成員key，對這個key所指向的地址進行值的修改，進而達到喚醒和休眠的目的
20    park          note

21    // 全部m組成的一個鏈表
22    alllink       *m       // on allm
23    // 下一個m，經過這個字段和sched.midle 能夠串成一個m的空閒鏈表
24    schedlink     muintptr
25    // mcache，m擁有p的時候，會把本身的mcache給p
26    mcache        *mcache
27    // lockedm的對應值
28    lockedg       guintptr
29    // 待釋放的m的list，經過sched.freem 串成一個鏈表
30    freelink      *m      // on sched.freem
31 }

　　和G相似，M中也有alllink域將全部的M放在allm鏈表中。lockedg是某些狀況下，G鎖定在這個M中運行而不會切換到其它M中去。M中還有一個MCache，是當前M的內存的緩存。M也和G同樣有一個常駐寄存器變量，表明當前的M。同時存在多個M，表示同時存在多個物理線程。

2.4 Sched結構體

　　Sched是調度實現中使用的數據結構，該結構體的定義在文件proc.c中。

 1 type schedt struct {
 2    // 全局的go id分配
 3    goidgen  uint64
 4    // 記錄的最後一次從i/o中查詢g的時間
 5    lastpoll uint64
 6 
 7    lock mutex
 8 
 9    //當增長nmidle，nmidlelocked，nmsys或nmfreed時，應
10    //確保調用checkdead（）。
11 
12      // m的空閒鏈表，結合m.schedlink 就能夠組成一個空閒鏈表了
13    midle        muintptr // idle m's waiting for work
14    nmidle       int32    // number of idle m's waiting for work
15    nmidlelocked int32    // number of locked m's waiting for work
16    // 下一個m的id，也用來記錄建立的m數量
17    mnext        int64    // number of m's that have been created and next M ID
18    // 最多容許的m的數量
19    maxmcount    int32    // maximum number of m's allowed (or die)
20    nmsys        int32    // number of system m's not counted for deadlock
21    // free掉的m的數量，exit的m的數量
22    nmfreed      int64    // cumulative number of freed m's
23 
24    ngsys uint32 // 系統goroutine的數量；原子更新
25 
26    pidle      puintptr // 閒置的
27    npidle     uint32
28    nmspinning uint32 // See "Worker thread parking/unparking" comment in proc.go.
29 
30    // Global runnable queue.
31    // 這個就是全局的g的隊列了，若是p的本地隊列沒有g或者太多，會跟全局隊列進行平衡
32    // 根據runqhead能夠獲取隊列頭的g，而後根據g.schedlink 獲取下一個，從而造成了一個鏈表
33    runqhead guintptr
34    runqtail guintptr
35    runqsize int32
36 
37    // freem是m等待被釋放時的列表
38    //設置了m.exited。經過m.freelink連接。
39 
40    // 等待釋放的m的列表
41    freem *m
42 }

　　大多數須要的信息都已放在告終構體M、G和P中，Sched結構體只是一個殼。能夠看到，其中有M的idle隊列，P的idle隊列，以及一個全局的就緒的G隊列。Sched結構體中的Lock是很是必須的，若是M或P等作一些非局部的操做，它們通常須要先鎖住調度器。

3. G、P、M相關狀態

g.status

• _Gidle: goroutine剛剛建立尚未初始化
• _Grunnable: goroutine處於運行隊列中，可是尚未運行，沒有本身的棧
• _Grunning: 這個狀態的g可能處於運行用戶代碼的過程當中，擁有本身的m和p
• _Gsyscall: 運行systemcall中
• _Gwaiting: 這個狀態的goroutine正在阻塞中，相似於等待channel
• _Gdead: 這個狀態的g沒有被使用，有多是剛剛退出，也有多是正在初始化中
• _Gcopystack: 表示g當前的棧正在被移除，新棧分配中

p.status

• _Pidle: 空閒狀態，此時p不綁定m
• _Prunning: m獲取到p的時候，p的狀態就是這個狀態了，而後m可使用這個p的資源運行g
• _Psyscall: 當go調用原生代碼，原生代碼又反過來調用go的時候，使用的p就會變成此態
• _Pdead: 當運行中，須要減小p的數量時，被減掉的p的狀態就是這個了

m.status

m的status沒有p、g的那麼明確，可是在運行流程的分析中，主要有如下幾個狀態

• 運行中: 拿到p，執行g的過程當中
• 運行原生代碼: 正在執行原聲代碼或者阻塞的syscall
• 休眠中: m發現無待運行的g時，進入休眠，並加入到空閒列表中
• 自旋中(spining): 當前工做結束，正在尋找下一個待運行的g

4. G、P、M的調度關係

　　一個G就是一個gorountine，保存了協程的棧、程序計數器以及它所在M的信息。P全稱是Processor，處理器，它的主要用途就是用來執行goroutine的。M表明內核級線程，一個M就是一個線程，goroutine就是跑在M之上的。程序啓動時，會建立一個主G，而每使用一次go關鍵字也建立一個G。go func()建立一個新的G後，放到P的本地隊列裏，或者平衡到全局隊列，而後檢查是否有可用的M，而後喚醒或新建一個M，M獲取待執行的G和空閒的P，將調用參數保存到g的棧，將sp，pc等上下文環境保存在g的sched域，這樣整個goroutine就準備好了，只要等分配到CPU，它就能夠繼續運行，以後再清理現場，從新進入調度循環。

 

4.1 調度實現

　　圖中有兩個物理線程，M0、M1每個M都擁有一個處理器P，每個P都有一個正在運行的G。P的數量能夠經過GOMAXPROCS()來設置，它其實也表明了真正的併發度，即有多少個goroutine能夠同時運行。圖中灰色goroutine都是處於ready的就緒態，正在等待被調度。由P維護這個就緒隊列（runqueue），go function每啓動一個goroutine，runqueue隊列就在其末尾加入一個goroutine，在下一個調度點，就從runqueue中取出一個goroutine執行。

　　當一個OS線程M0陷入阻塞時，P轉而在M1上運行G，圖中的M1多是正被建立，或者從線程緩存中取出。當MO返回時，它嘗試取得一個P來運行goroutine，通常狀況下，它會從其餘的OS線程那裏拿一個P過來執行，像M1獲取P同樣；若是沒有拿到的話，它就把goroutine放在一個global runqueue（全局運行隊列）裏，而後本身睡眠（放入線程緩存裏）。全部的P會週期性的檢查全局隊列並運行其中的goroutine，不然其上的goroutine永遠沒法執行。

　　另外一種狀況是P上的任務G很快就執行完了（分配不均），這個處理器P很忙，可是其餘的P還有任務，此時若是global runqueue也沒有G了，那麼P就會從其餘的P裏拿一些G來執行。通常來講，若是通常就拿run queue的一半，這就確保了每一個OS線程都能充分的使用。

　　golang採用了m:n線程模型，即m個gorountine（簡稱爲G）映射到n個用戶態進程（簡稱爲P）上，多個G對應一個P，一個P對應一個內核線程（簡稱爲M）。

 

　　P的數量：由啓動時環境變量$GOMAXPROCS或者是由runtime的方法GOMAXPROCS()決定（默認是1）。這意味着在程序執行的任意時刻都只有$GOMAXPROCS個goroutine在同時運行。在肯定了P的最大數量n後，運行時系統會根據這個數量建立n個P。

 　　M的數量：go語言自己的限制：go程序啓動時，會設置M的最大數量，默認10000.可是內核很難支持這麼多的線程數，因此這個限制能夠忽略。runtime/debug中的SetMaxThreads函數，設置M的最大數量。一個M阻塞了，會建立新的M。

M與P的數量沒有絕對關係，一個M阻塞，P就會去建立或者切換另外一個M，因此，即便P的默認數量是1，也有可能會建立不少個M出來。

 

　　P上G的調度：若是一個G不主動讓出cpu或被動block，所屬P中的其餘G會一直等待順序執行。

　　一個G執行IO時可能會進入waiting狀態，主動讓出CPU，此時會被移到所屬P中的其餘G後面，等待下一次輪到執行。

　　一個G調用了runtime.Gosched()會進入runnable狀態，主動讓出CPU，並被放到全局等待隊列中。

　　一個G調用了runtime.Goexit()，該G將會被當即終止，而後把已加載的defer（有點相似析構）依次執行完。

　　一個G調用了容許block的syscall，此時G及其對應的P、其餘G和M都會被block起來，監控線程M會定時掃描全部P，一旦發現某個P處於block syscall狀態，則通知調度器讓另外一個M來帶走P（這裏的另外一個M多是新建立的，所以隨着G被不斷block，M數量會不斷增長，最終M數量可能會超過P數量），這樣P及其他下的G就不會被block了，等被block的M返回時發現本身的P沒有了，也就不能再處理G了，因而將G放入全局等待隊列等待空閒P接管，而後M本身sleep。

經過實驗，當一個G運行了好久（好比進入死循環），會被自動切到其餘CPU核，多是由於超過期間片後G被移到全局等待隊列中，後面被其餘CPU核上的M處理。

　　M上P和G的調度：每當一個G要開始執行時，調度器判斷當前M的數量是否能夠很好處理完G：若是M少G多且有空閒P，則新建M或喚醒一個sleep M，並指定使用某個空閒P；若是M應付得來，G被負載均衡放入一個現有P+M中。

　　當M處理完其身上的全部G後，會再去全局等待隊列中找G，若是沒有就從其餘P中分一半的G（以便保證各個M處理G的負載大體相等），若是尚未，M就去sleep了，對應的P變爲空閒P。

在M進入sleep期間，調度器可能會給其P不斷放入G，等M醒後（好比超時）：若是G數量很少，則M直接處理這些G；若是M以爲G太多且有空閒P，會先主動喚醒其餘sleep的M來分擔G，若是沒有其餘sleep的M，調度器建立新M來分擔。

協程特色

　　協程擁有本身的寄存器上下文和棧。協程調度切換時，將寄存器上下文和棧保存到其餘地方，在切回來的時候，恢復先前保存的寄存器上下文和棧。所以，協程能保留上一次調用時的狀態（即全部局部狀態的一個特定組合），每次過程重入時，就至關於進入上一次調用的狀態，換種說法：進入上一次離開時所處邏輯流的位置。線程和進程的操做是由程序觸發系統接口，最後的執行者是系統；協程的操做執行者則是用戶自身程序，goroutine也是協程。