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也是协程。