前面的两篇，从相对比较简单的锁的内容入手(也是干货满满)，开始了go的系列。这篇开始，进入更核心的内容。我们知道，go应该是第一门在语言层面支持协程的编程语言(可能是我孤陋寡闻)，goroutine也完全算的上是go的门面。golang围绕着goroutine构建了一整套用户态的调度体系，并不断演进至当前的GMP模型。接下来相当的一段时间，我们应该都会在介绍GMP以及调度机制中度过。

本篇呢，我们就从goroutine开始说起。之所以从goroutine开始说起，是因为从我的角度来说，相比M和P，G是最简单的。G完全就是一个用户态的任务，唯一要做的就是记录任务的状态，并管理任务(或者说被管理)。其中管理任务包括，选择一个ready的任务运行、将阻塞的任务挂在到相应的阻塞队列中、将ready的任务移动到就绪队列。

当然，实际的实现远远比这复杂，但不妨碍我们先忽略一些细节，比如gc相关的内容等，先将主干抽离出来，理解其设计主线。

本文的内容主要是围绕下面的状态图，当然里面的内容不够全面。但就像前面说的，先理解主干，更多的细节在完整介绍完GMP后再进行补充。

对象

g

goroutine本质就是一个任务，可以被运行，可以等待，可以被调度。基于此，首先要有一个结构体，记录任务相关的信息。基本的信息包括任务的内容、任务的状态、运行任务所需的资源等。不只goroutine，包括其他一些计算机领域更广为人知的典型的任务，比如进程、线程等，都是如此。不过不同的任务，基于其自身的特性以及各自的迭代又会有特有的字段。

goroutine对应的对象如下。字段看上去不少，但是刨除一些gc、pprof(观测，不确定都是pprof相关)的字段，其实内容并不多，主要如下图所示。接下来我们一一介绍。

• 栈相关。
  stack表示goroutine的栈，栈是一块从高向低增长的线性内存，所以用lo和hi两个指针完全可以表示。

type stack struct {
   lo uintptr
   hi uintptr
}

stackguard0的作用是为了判断栈的扩张。

goroutine初始化的时候只会分配固定大小的栈，并且初始化的栈一定不会分配太大(2KB)。当goroutine运行过程中分配的栈内存越来越多，栈向下增长超过lo+StackGuard时就需要对栈进行扩张。同时stackguard0还可以设置为stackPreempt，表示该协程需要被抢占。goroutine检查到stackPreempt后会主动调度退出运行。stackguard0被检查的时机就是在发生函数调用时，所以我们说goroutine主动调度的时机除了阻塞时，就是在函数调用时。

stackguard1的作用和stackguard0的作用完全相同，stackguard1用来做c的栈的判断，这块我是完全不懂。

• _panic和_defer。这是golang的panic和defer特性，其实现是绑定于goroutine的，和我之前想的不一样。后面可以开一篇单独介绍。
• 调度相关。sched字段在goroutine被调度时记录其状态，主要是sp和pc，这两个字段可以记录goroutine的运行状态。

type gobuf struct {
   sp   uintptr
   pc   uintptr
   g    guintptr
   ctxt unsafe.Pointer
   ret  uintptr
   lr   uintptr
   bp   uintptr // for framepointer-enabled architectures
}

• 其他。其他的字段比如atomicstatus、goid、m等相对比较简单，就不占篇幅在这里说。

g结构体如下。

// src/runtime2.go 407
type g struct {
   stack       stack   // offset known to runtime/cgo
   stackguard0 uintptr // offset known to liblink
   stackguard1 uintptr // offset known to liblink

   _panic    *_panic // innermost panic - offset known to liblink
   _defer    *_defer // innermost defer
   m         *m      // current m; offset known to arm liblink
   sched     gobuf
   syscallsp uintptr // if status==Gsyscall, syscallsp = sched.sp to use during gc
   syscallpc uintptr // if status==Gsyscall, syscallpc = sched.pc to use during gc
   stktopsp  uintptr // expected sp at top of stack, to check in traceback

   param        unsafe.Pointer
   atomicstatus uint32
   stackLock    uint32 // sigprof/scang lock; TODO: fold in to atomicstatus
   goid         int64
   schedlink    guintptr
   waitsince    int64      // approx time when the g become blocked
   waitreason   waitReason // if status==Gwaiting

   preempt       bool // preemption signal, duplicates stackguard0 = stackpreempt
   preemptStop   bool // transition to _Gpreempted on preemption; otherwise, just deschedule
   preemptShrink bool // shrink stack at synchronous safe point

   asyncSafePoint bool

   paniconfault bool // panic (instead of crash) on unexpected fault address
   gcscandone   bool // g has scanned stack; protected by _Gscan bit in status
   throwsplit   bool // must not split stack
   activeStackChans bool
   parkingOnChan uint8
   
   // 下面都是观测及gc相关的，可以略过
   raceignore     int8     // ignore race detection events
   sysblocktraced bool     // StartTrace has emitted EvGoInSyscall about this goroutine
   tracking       bool     // whether we're tracking this G for sched latency statistics
   trackingSeq    uint8    // used to decide whether to track this G
   runnableStamp  int64    // timestamp of when the G last became runnable, only used when tracking
   runnableTime   int64    // the amount of time spent runnable, cleared when running, only used when tracking
   sysexitticks   int64    // cputicks when syscall has returned (for tracing)
   traceseq       uint64   // trace event sequencer
   tracelastp     puintptr // last P emitted an event for this goroutine
   lockedm        muintptr
   sig            uint32
   writebuf       []byte
   sigcode0       uintptr
   sigcode1       uintptr
   sigpc          uintptr
   gopc           uintptr         // pc of go statement that created this goroutine
   ancestors      *[]ancestorInfo // ancestor information goroutine(s) that created this goroutine (only used if debug.tracebackancestors)
   startpc        uintptr         // pc of goroutine function
   racectx        uintptr
   waiting        *sudog         // sudog structures this g is waiting on (that have a valid elem ptr); in lock order
   cgoCtxt        []uintptr      // cgo traceback context
   labels         unsafe.Pointer // profiler labels
   timer          *timer         // cached timer for time.Sleep
   selectDone     uint32         // are we participating in a select and did someone win the race?

   goroutineProfiled goroutineProfileStateHolder
   gcAssistBytes int64
}

sudog

除了g对象外，goroutine还涉及到sudog的对象。sudog是为了goroutine的阻塞队列而封装的一层对象。sudog的封装在我看来是出于两点考虑：

• 一个goroutine可以阻塞在多个资源上，也就是可能存在于多个阻塞队列中。针对这种情况，做一层封装会简化并发操作，每个sudog都是独属于某个阻塞队列的。
• 阻塞队列本身即具有一定的数据结构，封装sudog可以将阻塞队列的结构和g本身隔离出来，相当于某种程度的分层。例如在之前介绍的golang的sync.Mutex实现中，就涉及到红黑树以及链表的结构。

// src/runtime2.go 338
type sudog struct {
   g *g

   next *sudog
   prev *sudog
   elem unsafe.Pointer // data element (may point to stack)

   acquiretime int64
   releasetime int64
   ticket      uint32

   isSelect bool

   success bool

   parent   *sudog // semaRoot binary tree
   waitlink *sudog // g.waiting list or semaRoot
   waittail *sudog // semaRoot
   c        *hchan // channel
}

g的调度

goroutine的调度通常涉及到三种情况(最基本的三种)：

• goroutine处于running状态，主动调度；
• goroutine处于running状态，遇到阻塞时间，转换为waiting状态，触发调度；
• goroutine处于waiting状态，等待条件达成，转换为runnable状态，等待执行；

主动调度

go的runtime包提供了显示调度的方法runtime.Gosched()。
其调用了mcall函数，并将gosched_m函数作为参数传入。

// src/proc.go 316
func Gosched() {
   checkTimeouts()
   mcall(gosched_m)
}

先看下mcall函数。mcall是用汇编写的，这里就不贴汇编代码，感兴趣的小伙伴可以自行了解下plan9。从注释里看，mcall做的事情是：

• 将curg的PC/SP保存至g->sched中。g->sched在第一小节中我们也提到过，是goroutine被调度时记录其状态的字段。其中主要是PC/SP两个字段，PC记录当前goroutine执行到哪条指令，SP记录的是栈顶。
• 从curg切换至g0。g0是和每个m绑定的，不会执行用户任务，只执行系统任务。通常也把切换至g0称为切换至系统栈。
• 将curg作为参数传入fn中。fn做的事通常是对curg做一些操作，然后调度至新的goroutine继续执行。实际上，我们上面说的几种调度的情况，只是通过不同的fn参数来实现。
  mcall的这种实现实际也是一种代码复用和抽象的小技巧。

再回到gosched_m函数，实际是调用了goschedImpl函数。
goschedImpl中将curg的状态从_Grunning置为_Grunnable，因为这里是主动的调度，当前goroutine并没有被阻塞。
然后将curg和m进行解绑，并将curg塞到全局的阻塞队列中。
然后调用schedule函数。schedule会寻找到一个可执行的g，并切换至起执行。
流程图如下。

// Gosched continuation on g0.
func gosched_m(gp *g) {
   if trace.enabled {
      traceGoSched()
   }
   goschedImpl(gp)
}

func goschedImpl(gp *g) {
   status := readgstatus(gp)
   if status&^_Gscan != _Grunning {
      dumpgstatus(gp)
      throw("bad g status")
   }
   casgstatus(gp, _Grunning, _Grunnable)
   dropg()
   lock(&sched.lock)
   globrunqput(gp)
   unlock(&sched.lock)

   schedule()
}

schedule是很核心的函数，行数也比较多。我们还是忽略一些细节(细节的部分我们在m和p都有一定的了解后再来补充)，抽出主干，代码如下。

找到一个可执行的g，然后运行。

// src/proc.go 3185
// One round of scheduler: find a runnable goroutine and execute it.
// Never returns.
func schedule() {
   _g_ := getg()

   gp, inheritTime, tryWakeP := findRunnable() // blocks until work is available

   execute(gp, inheritTime)
}

execute会中会做状态的转换，然后运行gogo。gogo的参数是g->sched，gogo同样是汇编实现，其直接设置pc及sp将执行流切换至g。

func execute(gp *g, inheritTime bool) {
   _g_ := getg()
   
   _g_.m.curg = gp
   gp.m = _g_.m
   casgstatus(gp, _Grunnable, _Grunning)
   gp.waitsince = 0
   gp.preempt = false
   gp.stackguard0 = gp.stack.lo + _StackGuard
   if !inheritTime {
      _g_.m.p.ptr().schedtick++
   }

   gogo(&gp.sched)
}

goroutine阻塞

当goroutine运行遇到需要等待某些条件时，就会进入等待状态。将当前goroutine挂载到相应的阻塞队列，并触发调度。schedule的内容同上面没有变化，可见schedule是调度的核心，不同的调度方法只是在封装了在不同场景下的细节 。流程图如下。

func gopark(unlockf func(*g, unsafe.Pointer) bool, lock unsafe.Pointer, reason waitReason, traceEv byte, traceskip int) {
   if reason != waitReasonSleep {
      checkTimeouts() // timeouts may expire while two goroutines keep the scheduler busy
   }
   mp := acquirem()
   gp := mp.curg
   status := readgstatus(gp)
   if status != _Grunning && status != _Gscanrunning {
      throw("gopark: bad g status")
   }
   mp.waitlock = lock
   mp.waitunlockf = unlockf
   gp.waitreason = reason
   mp.waittraceev = traceEv
   mp.waittraceskip = traceskip
   releasem(mp)
   // can't do anything that might move the G between Ms here.
   mcall(park_m)
}

// park continuation on g0.
func park_m(gp *g) {
   _g_ := getg()

   if trace.enabled {
      traceGoPark(_g_.m.waittraceev, _g_.m.waittraceskip)
   }

   casgstatus(gp, _Grunning, _Gwaiting)
   dropg()

   if fn := _g_.m.waitunlockf; fn != nil {
      ok := fn(gp, _g_.m.waitlock)
      _g_.m.waitunlockf = nil
      _g_.m.waitlock = nil
      if !ok {
         if trace.enabled {
            traceGoUnpark(gp, 2)
         }
         casgstatus(gp, _Gwaiting, _Grunnable)
         execute(gp, true) // Schedule it back, never returns.
      }
   }
   schedule()
}

goroutine就绪

goroutine从等待状态转变为就绪状态应该是最简单的，因为其不涉及调度。只是将g的状态改变，并将g从阻塞队列移动至当前的就绪队列。流程图如下。

唯一有点意思的点在于wakep。wakep的作用是 当有新的g就绪，而当前系统的负载又很低时，确保有m和p来及时的运行g。这个后面在m和p的部分回详细介绍。

func goready(gp *g, traceskip int) {
   systemstack(func() {
      ready(gp, traceskip, true)
   })
}

// Mark gp ready to run.
func ready(gp *g, traceskip int, next bool) {
   if trace.enabled {
      traceGoUnpark(gp, traceskip)
   }

   status := readgstatus(gp)

   // Mark runnable.
   _g_ := getg()
   mp := acquirem() // disable preemption because it can be holding p in a local var
   if status&^_Gscan != _Gwaiting {
      dumpgstatus(gp)
      throw("bad g->status in ready")
   }

   // status is Gwaiting or Gscanwaiting, make Grunnable and put on runq
   casgstatus(gp, _Gwaiting, _Grunnable)
   runqput(_g_.m.p.ptr(), gp, next)
   wakep()
   releasem(mp)
}

---

本篇呢，对goroutine的介绍肯定不算面面俱到。毕竟，抛开M和P来讲G是很难讲全的。但是，我相信，读过本篇一定会对goroutine建立基本的认知。这种认知不够细节，但一定足够本质。就像文章开头说的，goroutine就是一个用户态的任务。我们自己其实也可以很轻易的实现一个任务管理的系统，这本质上就没有区别。当然，goroutine具备了很多的go的特性，肯定是复杂的多。