GO GMP协程调度实现原理 5w字长文史上最全

1 Runtime简介

Go语言是互联网时代的C，因为其语法简洁易学，对高并发拥有语言级别的亲和性。而且不同于虚拟机的方案。Go通过在编译时嵌入平台相关的系统指令可直接编译为对应平台的机器码，同时嵌入Go Runtime，在运行时实现自身的调度算法和各种并发控制方案，避免进入操作系统级别的进程/线程上下文切换，以及通过原子操作、自旋、信号量、全局哈希表、等待队列多种技术避免进入操作系统级别锁，以此来提升整体性能。

Go的runtime是与用户代码一起打包在一个可执行文件中，是程序的一部分，而不是向Java需要单独安装，与程序独立。所以用户代码与runtime代码在执行时没有界限都是函数调用。在Go语言中的关键字编译时会变成runtime中的函数调用。

Go Runtime核心主要涉及三大部分：内存分配、调度算法、垃圾回收；本篇文章我们主要介绍GMP调度原理。关于具体应该叫GPM还是GMP，我更倾向于成为GMP，因为在runtime代码中经常看到如下调用：

1 buf := &getg().m.p.ptr().wbBuf

其中getg代表获取当前正在运行的g即goroutine，m代表对应的逻辑处理器，p是逻辑调度器；所以我们还是称为GMP。

（以上部分图文来自：https://zhuanlan.zhihu.com/p/95056679）

2 GMP概览

下面这个图虽然有些抽象（不如花花绿绿的图片），确是目前我看到对整个调度算法设计的重要概念覆盖最全的。

 1                             +-------------------- sysmon ---------------//------+ 
 2                             |                                                   |
 3                             |                                                   |
 4                +---+      +---+-------+                   +--------+          +---+---+
 5 go func() ---> | G | ---> | P | local | <=== balance ===> | global | <--//--- | P | M |
 6                +---+      +---+-------+                   +--------+          +---+---+
 7                             |                                 |                 | 
 8                             |      +---+                      |                 |
 9                             +----> | M | <--- findrunnable ---+--- steal <--//--+
10                                    +---+ 
11                                      |
12                                    mstart
13                                      |
14               +--- execute <----- schedule 
15               |                      |   
16               |                      |
17               +--> G.fn --> goexit --+

我们来看下其中的三大主要概念：

G：Groutine协程，拥有运行函数的指针、栈、上下文（指的是sp、bp、pc等寄存器上下文以及垃圾回收的标记上下文），在整个程序运行过程中可以有无数个，代表一个用户级代码执行流（用户轻量级线程）；
P：Processor，调度逻辑处理器，同样也是Go中代表资源的分配主体（内存资源、协程队列等），默认为机器核数，可以通过GOMAXPROCS环境变量调整
M：Machine，代表实际工作的执行者，对应到操作系统级别的线程；M的数量会比P多，但不会太多，最大为1w个。

其中G分为三类：

主协程，用来执行用户main函数的协程
主协程创建的协程，也是P调度的主要成员
G0，每个M都有一个G0协程，他是runtime的一部分，G0是跟M绑定的，主要用来执行调度逻辑的代码，所以不能被抢占也不会被调度（普通G也可以执行runtime_procPin禁止抢占），G0的栈是系统分配的，比普通的G栈（2KB）要大，不能扩容也不能缩容
sysmon协程，sysmon协程也是runtime的一部分，sysmon协程直接运行在M不需要P，主要做一些检查工作如：检查死锁、检查计时器获取下一个要被触发的计时任务、检查是否有ready的网络调用以恢复用户G的工作、检查一个G是否运行时间太长进行抢占式调度。

M分为两类：

普通M，用来与P绑定执行G中任务
m0：Go程序是一个进程，进程都有一个主线程，m0就是Go程序的主线程，通过一个与其绑定的G0来执行runtime启动加载代码；一个Go程序只有一个m0
运行sysmon的M，主要用来运行sysmon协程。

刚才说道P是用来调度G的执行，所以每个P都有自己的一个G的队列，当G队列都执行完毕后，会从global队列中获取一批G放到自己的本地队列中，如果全局队列也没有待运行的G，则P会再从其他P中窃取一部分G放到自己的队列中。而调度的时机一般有三种：

主动调度，协程通过调用`runtime.Goshed`方法主动让渡自己的执行权利，之后这个协程会被放到全局队列中，等待后续被执行
被动调度，协程在休眠、channel通道阻塞、网络I/O堵塞、执行垃圾回收时被暂停，被动式让渡自己的执行权利。大部分场景都是被动调度，这是Go高性能的一个原因，让M永远不停歇，不处于等待的协程让出CPU资源执行其他任务。
抢占式调度，这个主要是sysmon协程上的调度，当发现G处于系统调用（如调用网络io）超过20微秒或者G运行时间过长（超过10ms），会抢占G的执行CPU资源，让渡给其他协程；防止其他协程没有执行的机会；（系统调用会进入内核态，由内核线程完成，可以把当前CPU资源让渡给其他用户协程）

Go的协程调度与操作系统线程调度区别主要存在四个方面：

调度发生地点：Go中协程的调度发生在runtime，属于用户态，不涉及与内核态的切换；一个协程可以被切换到多个线程执行
上下文切换速度：协程的切换速度远快于线程，不需要经过内核与用户态切换，同时需要保存的状态和寄存器非常少；线程切换速度为1-2微秒，协程切换速度为0.2微秒左右
调度策略：线程调度大部分都是抢占式调度，操作系统通过发出中断信号强制线程切换上下文；Go的协程基本是主动和被动式调度，调度时机可预期
栈大小：线程栈一般是2MB，而且运行时不能更改大小；Go的协程栈只有2kb，而且可以动态扩容（64位机最大为1G）

以上基本是整个调度器的概括，不想看原理的同学可以不用往下看了，下面会进行源码级介绍；

3 GMP的源码结构

源码部分主要涉及三个文件：

1 runtime/amd_64.s 涉及到进程启动以及对CPU执行指令进行控制的汇编代码，进程的初始化部分也在这里面
2 runtime/runtime2.go 这里主要是运行时中一些重要数据结构的定义，比如g、m、p以及涉及到接口、defer、panic、map、slice等核心类型
3 runtime/proc.go 一些核心方法的实现，涉及gmp调度等核心代码在这里

这里我们主要关心gmp中与调度相关的代码；

3.1 G源码部分

3.1.1 G的结构

先来看下g的结构定义：

 1 // runtime/runtime2.go
 2 type g struct {
 3    // 记录协程栈的栈顶和栈底位置
 4    stack       stack   // offset known to runtime/cgo
 5    // 主要作用是参与一些比较计算，当发现容量要超过栈分配空间后，可以进行扩容或者收缩
 6    stackguard0 uintptr // offset known to liblink
 7    stackguard1 uintptr // offset known to liblink
 8 
 9    // 当前与g绑定的m
10    m         *m      // current m; offset known to arm liblink
11    // 这是一个比较重要的字段，里面保存的一些与goroutine运行位置相关的寄存器和指针，如rsp、rbp、rpc等寄存器
12    sched     gobuf
13    syscallsp uintptr // if status==Gsyscall, syscallsp = sched.sp to use during gc
14    syscallpc uintptr // if status==Gsyscall, syscallpc = sched.pc to use during gc
15    stktopsp  uintptr // expected sp at top of stack, to check in traceback
16  
17    // 用于做参数传递，睡眠时其他goroutine可以设置param，唤醒时该g可以读取这些param
18    param        unsafe.Pointer
19    // 记录当前goroutine的状态
20    atomicstatus uint32
21    stackLock    uint32 // sigprof/scang lock; TODO: fold in to atomicstatus
22    // goroutine的唯一id
23    goid         int64
24    schedlink    guintptr
25    
26    // 标记是否可以被抢占
27    preempt       bool // preemption signal, duplicates stackguard0 = stackpreempt
28    preemptStop   bool // transition to _Gpreempted on preemption; otherwise, just deschedule
29    preemptShrink bool // shrink stack at synchronous safe point
30 
31    // 如果调用了LockOsThread方法，则g会绑定到某个m上，只在这个m上运行
32    lockedm        muintptr
33    sig            uint32
34    writebuf       []byte
35    sigcode0       uintptr
36    sigcode1       uintptr
37    sigpc          uintptr
38    // 创建该goroutine的语句的指令地址
39    gopc           uintptr         // pc of go statement that created this goroutine
40    ancestors      *[]ancestorInfo // ancestor information goroutine(s) that created this goroutine (only used if debug.tracebackancestors)
41    // goroutine函数的指令地址
42    startpc        uintptr         // pc of goroutine function
43    racectx        uintptr
44    waiting        *sudog         // sudog structures this g is waiting on (that have a valid elem ptr); in lock order
45    cgoCtxt        []uintptr      // cgo traceback context
46    labels         unsafe.Pointer // profiler labels
47    timer          *timer         // cached timer for time.Sleep
48    selectDone     uint32         // are we participating in a select and did someone win the race?
49 }

跟g相关的还有两个数据结构比较重要：

stack是协程栈的地址信息，需要注意的是m0绑定的g0是在进程被分配的系统栈上分配协程栈的，而其他协程栈都是在堆上进行分配的。

gobuf中保存了协程执行的上下文信息，这里也可以看到协程切换的上下文信息极少；sp代表cpu的rsp寄存器的值，pc代表CPU的rip寄存器值、bp代表CPU的rbp寄存器值；ret用来保存系统调用的返回值，ctxt在gc的时候使用。

其中几个寄存器作用如下：

SP：永远指向栈顶位置
BP：某一时刻的栈顶位置，当新函数调用时，把当前SP地址赋值给BP、SP指向新的栈顶位置
PC：代表代码经过编译为机器码后，当前执行的机器指令（可以理解为当前语句）

 1 // Stack describes a Go execution stack.
 2 // The bounds of the stack are exactly [lo, hi),
 3 // with no implicit data structures on either side.
 4 // goroutine协程栈的栈顶和栈底
 5 type stack struct {
 6    lo uintptr // 栈顶，低地址
 7    hi uintptr // 栈底，高地址
 8 }
 9 
10 // gobuf中保存了非常重要的上下文执行信息，
11 type gobuf struct {
12     // 代表cpu的rsp寄存器的值，永远指向栈顶位置
13    sp   uintptr
14    // 代表代码经过编译为机器码后，当前执行的机器指令（可以理解为当前语句）
15    pc   uintptr
16    // 指向所保存执行上下文的goroutine
17    g    guintptr
18    // gc时候使用
19    ctxt unsafe.Pointer
20    // 用来保存系统调用的返回值
21    ret  uintptr
22    lr   uintptr
23    // 某一时刻的栈顶位置，当新函数调用时，把当前SP地址赋值给BP、SP指向新的栈顶位置
24    bp   uintptr // for framepointer-enabled architectures
25 }

3.1.2 G的状态

就像线程有自己的状态一样，goroutine也有自己的状态，主要记录在atomicstatus字段上：

 1 // defined constants
 2 const (
 3     // 代表协程刚开始创建时的状态，当新创建的协程初始化后，为变为_Gdead状态，_Gdread也是协程被销毁时的状态；
 4     // 刚创建时也被会置为_Gdead主要是考虑GC可以去用去扫描dead状态下的协程栈
 5    _Gidle = iota // 0
 6     // 代表协程正在运行队列中，等待被运行
 7    _Grunnable // 1
 8     // 代表当前协程正在被运行，已经被分配了逻辑处理的线程，即p和m
 9    _Grunning // 2
10     // 代表当前协程正在执行系统调用
11    _Gsyscall // 3
12     // 表示当前协程在运行时被锁定，陷入阻塞，不能执行用户代码
13    _Gwaiting // 4
14 
15    _Gmoribund_unused // 5
16     // 新创建的协程初始化后，或者协程被销毁后的状态
17    _Gdead // 6
18 
19    // _Genqueue_unused is currently unused.
20    _Genqueue_unused // 7
21     // 代表在进行协程栈扫描时发现需要扩容或者缩容，将协程中的栈转移到新栈时的状态；这个时候不执行用户代码，也不在p的runq中
22    _Gcopystack // 8
23 
24     // 代表g被抢占后的状态
25    _Gpreempted // 9
26 
27     // 这几个状态是垃圾回收时涉及，后续文章进行介绍
28    _Gscan          = 0x1000
29    _Gscanrunnable  = _Gscan + _Grunnable  // 0x1001
30    _Gscanrunning   = _Gscan + _Grunning   // 0x1002
31    _Gscansyscall   = _Gscan + _Gsyscall   // 0x1003
32    _Gscanwaiting   = _Gscan + _Gwaiting   // 0x1004
33    _Gscanpreempted = _Gscan + _Gpreempted // 0x1009
34 )

这里是利用常量定义的枚举。

Go的状态变更可以看下图：

3.1.3 G的创建

当我们使用go关键字新建一个goroutine时，编译器会编译为runtime中对应的函数调用（newproc，而go 关键字后面的函数成为协程的任务函数），进行创建，整体步骤如下：

1. 用 systemstack 切换到系统堆栈，调用 newproc1 ，newproc1 实现g的获取。

2. 尝试从p的本地g空闲链表和全局g空闲链表找到一个g的实例。

3. 如果上面未找到，则调用 malg 生成新的g的实例，且分配好g的栈和设置好栈的边界，接着添加到 allgs 数组里面，allgs保存了所有的g。

4. 保存g切换的上下文，这里很关键，g的切换依赖 sched 字段。

5. 生成唯一的goid，赋值给该g。

6. 调用 runqput 将g插入队列中，如果本地队列还有剩余的位置，将G插入本地队列的尾部，若本地队列已满，插入全局队列。

7. 如果有空闲的p 且 m没有处于自旋状态 且 main goroutine已经启动，那么唤醒或新建某个m来执行任务。

这里对应的是newproc函数：

 1 func newproc(siz int32, fn *funcval) {
 2    argp := add(unsafe.Pointer(&fn), sys.PtrSize)
 3    gp := getg()
 4    // 获取调用者的指令地址，也就是调用newproc时又call指令压栈的函数返回地址
 5    pc := getcallerpc()
 6    // systemstack的作用是切换到m0对应的g0所属的系统栈
 7    // 使用g0所在的系统栈创建goroutine对象
 8    // 传递参数包括goroutine的任务函数、argp参数起始地址、siz是参数长度、调用方的pc指针
 9    systemstack(func() {
10       newg := newproc1(fn, argp, siz, gp, pc)
11       // 创建完成后将g放到创建者（某个g，如果是进程初始化启动阶段则为g0）所在的p的队列中
12       _p_ := getg().m.p.ptr()
13       runqput(_p_, newg, true)
14 
15       if mainStarted {
16          wakep()
17       }
18    })
19 }
其中systemstack是一段汇编代码，位于asm_amd64.s文件中，主要是寄存器指令的操作，笔者不懂汇编这里先不做介绍。
 
newproc1是获取newg的函数，主要步骤：
1、首先防止当前g被抢占，绑定m
2、对传入的参数占用的内存空间进行对齐处理
3、从p的空闲队列中获取一个空闲的g，如果么有就创建一个g，并在堆上创建协程栈，并设置状态为_Gdead添加到全局allgs中
4、计算整体协程任务函数的参数空间大小，并设置sp指针
5、执行参数从getg的堆栈到newg堆栈的复制
6、设置newg的sched和startpc、gopc等跟上下文相关的字段值
7、设置newg状态为runable并设置goid
8、接触getg与m的防抢占状态

代码注释如下：

  1 func newproc1(fn *funcval, argp unsafe.Pointer, narg int32, callergp *g, callerpc uintptr) *g {
  2     .....
  3     // 如果是初始化时候这个代表g0
  4    _g_ := getg()
  5 
  6    if fn == nil {
  7       _g_.m.throwing = -1 // do not dump full stacks
  8       throw("go of nil func value")
  9    }
 10    // 使_g_.m.locks++，来防止这个时候g对应的m被抢占
 11    acquirem() // disable preemption because it can be holding p in a local var
 12    // 参数的地址，下面一句目的是为了做到内存对齐
 13    siz := narg
 14    siz = (siz + 7) &^ 7
 15 
 16    // We could allocate a larger initial stack if necessary.
 17    // Not worth it: this is almost always an error.
 18    // 4*PtrSize: extra space added below
 19    // PtrSize: caller's LR (arm) or return address (x86, in gostartcall).
 20    if siz >= _StackMin-4*sys.PtrSize-sys.PtrSize {
 21       throw("newproc: function arguments too large for new goroutine")
 22    }
 23 
 24    _p_ := _g_.m.p.ptr()
 25    newg := gfget(_p_) // 首先从p的gfree队列中看看有没有空闲的g，有则使用
 26    if newg == nil {
 27        // 如果没找到就使用new关键字来创建一个g并在堆上分配栈空间
 28       newg = malg(_StackMin)
 29       // 将newg的状态设置为_Gdead，因为这样GC就不会去扫描一个没有初始化的协程栈
 30       casgstatus(newg, _Gidle, _Gdead)
 31       // 添加到全局的allg切片中（需要加锁访问）
 32       allgadd(newg) // publishes with a g->status of Gdead so GC scanner doesn't look at uninitialized stack.
 33    }
 34    // 下面是检查协程栈的创建情况和状态
 35    if newg.stack.hi == 0 {
 36       throw("newproc1: newg missing stack")
 37    }
 38 
 39    if readgstatus(newg) != _Gdead {
 40       throw("newproc1: new g is not Gdead")
 41    }
 42    // 计算运行空间大小并进行内存对齐
 43    totalSize := 4*sys.PtrSize + uintptr(siz) + sys.MinFrameSize // extra space in case of reads slightly beyond frame
 44    totalSize += -totalSize & (sys.StackAlign - 1)               // align to StackAlign
 45    // 计算sp寄存器指针的位置
 46    sp := newg.stack.hi - totalSize
 47    // 确定参数入栈位置
 48    spArg := sp
 49    .........
 50    if narg > 0 {
 51        // 将参数从newproc函数的栈复制到新的协程的栈中，memove是一段汇编代码
 52        // 从argp位置挪动narg大小的内存到sparg位置
 53       memmove(unsafe.Pointer(spArg), argp, uintptr(narg))
 54       // 因为涉及到从栈到堆栈上的复制，go在垃圾回收中使用了三色标记和写入屏障等手段，所以这里要考虑屏障复制
 55       // 目标栈可能会有垃圾存在，所以设置屏障并且标记为灰色
 56       if writeBarrier.needed && !_g_.m.curg.gcscandone { // 如果启用了写入屏障并且源堆栈为灰色（目标始终为黑色），则执行屏障复制。
 57          f := findfunc(fn.fn)
 58          stkmap := (*stackmap)(funcdata(f, _FUNCDATA_ArgsPointerMaps))
 59          if stkmap.nbit > 0 {
 60             // We're in the prologue, so it's always stack map index 0.
 61             bv := stackmapdata(stkmap, 0)
 62             bulkBarrierBitmap(spArg, spArg, uintptr(bv.n)*sys.PtrSize, 0, bv.bytedata)
 63          }
 64       }
 65    }
 66     // 把newg的sched结构体成员的所有字段都设置为0，其实就是初始化
 67    memclrNoHeapPointers(unsafe.Pointer(&newg.sched), unsafe.Sizeof(newg.sched))
 68    newg.sched.sp = sp
 69    newg.stktopsp = sp
 70    // pc指针表示当newg被调度起来时从这个位置开始执行
 71    // 这里是先设置为goexit，在gostartcallfn中会进行处理，更改sp为这里的pc，将pc改为真正的协程任务函数fn的指令位置
 72    // 这样使得任务函数执行完毕后，会继续执行goexit中相关的清理工作
 73    newg.sched.pc = abi.FuncPCABI0(goexit) + sys.PCQuantum // +PCQuantum so that previous instruction is in same function
 74    newg.sched.g = guintptr(unsafe.Pointer(newg)) // 保存当前的g
 75    gostartcallfn(&newg.sched, fn) // 在这里完成g启动时所有相关上下文指针的设置，主要为sp、pc和ctxt，ctxt被设置为fn
 76    newg.gopc = callerpc // 保存newproc的pc，即调用者创建时的指令位置
 77    newg.ancestors = saveAncestors(callergp)
 78    // 设置startpc为任务函数，主要用于函数调用栈的trackback和栈收缩工作
 79    // newg的执行开始位置并不依赖这个字段，而是通过sched.pc确定
 80    newg.startpc = fn.fn
 81    if _g_.m.curg != nil {
 82       newg.labels = _g_.m.curg.labels
 83    }
 84    // 判断newg的任务函数是不是runtime系统的任务函数，是则sched.ngsys+1；
 85    // 主协程则代表runtime.main函数，在这里就为判断为真
 86    if isSystemGoroutine(newg, false) {
 87       atomic.Xadd(&sched.ngsys, +1)
 88    }
 89    // Track initial transition?
 90    newg.trackingSeq = uint8(fastrand())
 91    if newg.trackingSeq%gTrackingPeriod == 0 {
 92       newg.tracking = true
 93    }
 94    // 更改当前g的状态为_Grunnable
 95    casgstatus(newg, _Gdead, _Grunnable)
 96     // 设置g的goid，因为p会每次批量生成16个id，每次newproc如果新建一个g，id就会加1
 97     // 所以这里m0的g0的id为0，而主协程的goid为1，其他的依次递增
 98    if _p_.goidcache == _p_.goidcacheend {
 99       // Sched.goidgen is the last allocated id,
100       // this batch must be [sched.goidgen+1, sched.goidgen+GoidCacheBatch].
101       // At startup sched.goidgen=0, so main goroutine receives goid=1.
102       // 使用原子操作修改全局变量，这里的sched是在runtime2.go中的一个全局变量类型为schedt
103       // 原子操作具有多线程可见性，同时比加锁性能更高
104       _p_.goidcache = atomic.Xadd64(&sched.goidgen, _GoidCacheBatch)
105       _p_.goidcache -= _GoidCacheBatch - 1
106       _p_.goidcacheend = _p_.goidcache + _GoidCacheBatch
107    }
108    newg.goid = int64(_p_.goidcache)
109    _p_.goidcache++
110    if raceenabled {
111       newg.racectx = racegostart(callerpc)
112    }
113    if trace.enabled {
114       traceGoCreate(newg, newg.startpc)
115    }
116    // 释放getg与m的绑定
117    releasem(_g_.m)
118 
119    return newg
120 }

其中有几个关键地方需要强调

3.1.4 协程栈在堆空间的分配malg函数，用来创建一个新g和对应的栈空间分配，这个函数主要强调的是栈空间分配部分，通过切换到系统栈上进行空间分配，分配完后设置栈底和栈顶的两个位置的保护字段，当栈上进行分配变量空间发现超过stackguard1时，会进行扩容，同时在某些条件下也会进行缩容

 1 // Allocate a new g, with a stack big enough for stacksize bytes.
 2 func malg(stacksize int32) *g {
 3    newg := new(g)
 4    if stacksize >= 0 {
 5       stacksize = round2(_StackSystem + stacksize)
 6       systemstack(func() {
 7          newg.stack = stackalloc(uint32(stacksize))
 8       })
 9       newg.stackguard0 = newg.stack.lo + _StackGuard
10       newg.stackguard1 = ^uintptr(0)
11       // Clear the bottom word of the stack. We record g
12       // there on gsignal stack during VDSO on ARM and ARM64.
13       *(*uintptr)(unsafe.Pointer(newg.stack.lo)) = 0
14    }
15    return newg
16 }

stackalloc代码位于runtime/stack.go文件中；

协程栈首先在进程初始化时会创建栈的管理结构：

1、栈池stackpool，这个栈池主要用来对大小为2、4、8kb的小栈做缓存使用，使用的同样是mspan这种结构来存储；

2、为大栈分配的stackLarge

 OS               | FixedStack | NumStackOrders
 -----------------+------------+---------------
 linux/darwin/bsd | 2KB        | 4
 windows/32       | 4KB        | 3
 windows/64       | 8KB        | 2
 plan9            | 4KB        | 3

// Global pool of spans that have free stacks.
// Stacks are assigned an order according to size.
//     order = log_2(size/FixedStack)
// There is a free list for each order.
var stackpool [_NumStackOrders]struct {
  item stackpoolItem
  _    [cpu.CacheLinePadSize - unsafe.Sizeof(stackpoolItem{})%cpu.CacheLinePadSize]byte
}

//go:notinheap
type stackpoolItem struct {
  mu   mutex
  span mSpanList
}

// Global pool of large stack spans.
var stackLarge struct {
  lock mutex
  free [heapAddrBits - pageShift]mSpanList // free lists by log_2(s.npages)
}

func stackinit() {
  if _StackCacheSize&_PageMask != 0 {
     throw("cache size must be a multiple of page size")
  }
  for i := range stackpool {
     stackpool[i].item.span.init()
     lockInit(&stackpool[i].item.mu, lockRankStackpool)
  }
  for i := range stackLarge.free {
     stackLarge.free[i].init()
     lockInit(&stackLarge.lock, lockRankStackLarge)
  }
}
stackalloc会首先判断栈空间大小，是大栈还是固定空间的小栈，
1、对于小栈，如果是还没有分配栈缓存空间，则进入stackpoolalloc函数进行分配空间（需要加锁），这里最终是从全局的mheap也就是堆空间中获取内存空间；如果有栈缓存空间，则从g对应的mcache中的stackcache上获取内存空间（无锁），如果stackcache上没有足够空间则调用stackcacherefill方法为stackpool进行扩容（也是从mheap中拿取，加锁）然后分配给协程
2、对于大栈，先从stackLarge中获取，如果没有则从mheap中获取，两个步骤都需要加载访问；
3、最后创建stack结构返回给newg

func stackalloc(n uint32) stack {
  // Stackalloc must be called on scheduler stack, so that we
  // never try to grow the stack during the code that stackalloc runs.
  // Doing so would cause a deadlock (issue 1547).
  thisg := getg()
.........

  // Small stacks are allocated with a fixed-size free-list allocator.
  // If we need a stack of a bigger size, we fall back on allocating
  // a dedicated span.
  var v unsafe.Pointer
  if n < _FixedStack<<_NumStackOrders && n < _StackCacheSize {
     order := uint8(0)
     n2 := n
     for n2 > _FixedStack {
        order++
        n2 >>= 1
     }
     var x gclinkptr
     if stackNoCache != 0 || thisg.m.p == 0 || thisg.m.preemptoff != "" {
        // thisg.m.p == 0 can happen in the guts of exitsyscall
        // or procresize. Just get a stack from the global pool.
        // Also don't touch stackcache during gc
        // as it's flushed concurrently.
        lock(&stackpool[order].item.mu)
        x = stackpoolalloc(order)
        unlock(&stackpool[order].item.mu)
     } else {
        c := thisg.m.p.ptr().mcache
        x = c.stackcache[order].list
        if x.ptr() == nil {
           stackcacherefill(c, order)
           x = c.stackcache[order].list
        }
        c.stackcache[order].list = x.ptr().next
        c.stackcache[order].size -= uintptr(n)
     }
     v = unsafe.Pointer(x)
  } else {
     var s *mspan
     npage := uintptr(n) >> _PageShift
     log2npage := stacklog2(npage)

     // Try to get a stack from the large stack cache.
     lock(&stackLarge.lock)
     if !stackLarge.free[log2npage].isEmpty() {
        s = stackLarge.free[log2npage].first
        stackLarge.free[log2npage].remove(s)
     }
     unlock(&stackLarge.lock)

     lockWithRankMayAcquire(&mheap_.lock, lockRankMheap)

     if s == nil {
        // Allocate a new stack from the heap.
        s = mheap_.allocManual(npage, spanAllocStack)
        if s == nil {
           throw("out of memory")
        }
        osStackAlloc(s)
        s.elemsize = uintptr(n)
     }
     v = unsafe.Pointer(s.base())
  }

  if raceenabled {
     racemalloc(v, uintptr(n))
  }
  if msanenabled {
     msanmalloc(v, uintptr(n))
  }
  if stackDebug >= 1 {
     print("  allocated ", v, "\n")
  }
  return stack{uintptr(v), uintptr(v) + uintptr(n)}
}
 
非g0的g为什么要在堆上分配空间？
虽然堆不如栈快，但是goroutine是go模拟的线程，具有动态扩容和缩容的能力，而系统栈是线性空间，在系统栈上发生缩容和扩容会存在空间不足或者栈空间碎片等问题；所以go这里在堆上分配协程栈；因为是在堆空间也就意味着这部分空间也需要进行垃圾回收和释放；所以Go的GC是多线程并发标记时，内存屏障是对整个协程栈标记灰色，来让回收器进行扫描。
1.5 G的上下文设置和切换协程栈的切换主要是在两个地方，由执行调度逻辑的g0切换到执行用户逻辑的g的过程，以及执行用户逻辑的g退出或者被抢占切换为g0执行调度的过程，抢占在下文中介绍
上面代码中当newg被初始化时，会初始化sched中的pc和sp指针，其中会把pc先设置为goexit函数的第二条指令。

   // 把newg的sched结构体成员的所有字段都设置为0，其实就是初始化
  memclrNoHeapPointers(unsafe.Pointer(&newg.sched), unsafe.Sizeof(newg.sched))
  newg.sched.sp = sp
  newg.stktopsp = sp
  // pc指针表示当newg被调度起来时从这个位置开始执行
  // 这里是先设置为goexit，在gostartcallfn中会进行处理，更改sp为这里的pc，将pc改为真正的协程任务函数fn的指令位置
  // 这样使得任务函数执行完毕后，会继续执行goexit中相关的清理工作
  newg.sched.pc = abi.FuncPCABI0(goexit) + sys.PCQuantum // +PCQuantum so that previous instruction is in same function
  newg.sched.g = guintptr(unsafe.Pointer(newg)) // 保存当前的g
  gostartcallfn(&newg.sched, fn) // 在这里完成g启动时所有相关上下文指针的设置，主要为sp、pc和ctxt，ctxt被设置为fn
  newg.gopc = callerpc // 保存newproc的pc，即调用者创建时的指令位置
然后进入gostartcallfn函数，最终是在gostartcall函数中进行处理

// gostartcallfn 位于runtime/stack.go中

func gostartcallfn(gobuf *gobuf, fv *funcval) {
  var fn unsafe.Pointer
  if fv != nil {
     fn = unsafe.Pointer(fv.fn)
  } else {
     fn = unsafe.Pointer(funcPC(nilfunc))
  }
  gostartcall(gobuf, fn, unsafe.Pointer(fv))
}

// gostartcall 位于runtime/sys_x86.go中

func gostartcall(buf *gobuf, fn, ctxt unsafe.Pointer) {
   // newg的栈顶，目前newg栈上只有fn函数的参数，sp指向的是fn的第一个参数
  sp := buf.sp
  // 为返回地址预留空间
  sp -= sys.PtrSize
  // buf.pc中设置的是goexit函数中的第二条指令
  // 因为栈是自顶向下，先进后出，所以这里伪装fn是被goexit函数调用的，goexit在前fn在后
  // 使得fn返回后到goexit继续执行，以完成一些清理工作。
  *(*uintptr)(unsafe.Pointer(sp)) = buf.pc
  buf.sp = sp // 重新设置栈顶
  // 将pc指向goroutine的任务函数fn，这样当goroutine获得执行权时，从任务函数入口开始执行
  // 如果是主协程，那么fn就是runtime.main，从这里开始执行
  buf.pc = uintptr(fn)
  buf.ctxt = ctxt
}
可以看到在newg初始化时进行的一系列设置工作，将goexit先压入栈顶，然后伪造sp位置，让cpu看起来是从goexit中调用的协程任务函数，然后将pc指针指向任务函数，当协程被执行时，从pc处开始执行，任务函数执行完毕后执行goexit；
 
这里是设置工作，具体的切换工作，需要经由schedule调度函数选中一个g，进入execute函数设置g的相关状态和栈保护字段等信息，然后进入gogo函数，通过汇编语言，将CPU寄存器以及函数调用栈切换为g的sched中相关指针和协程栈。gogo函数源码如下：

// gogo的具体汇编代码位于asm_amd64.s中

// func gogo(buf *gobuf)
// restore state from Gobuf; longjmp
TEXT runtime·gogo(SB), NOSPLIT, $0-8
   // 0（FP）表示第一个参数，即buf=&gp.sched
  MOVQ   buf+0(FP), BX     // gobuf
  // DX = gp.sched.g，DX代表数据寄存器
  MOVQ   gobuf_g(BX), DX
  MOVQ   0(DX), CX     // make sure g != nil
  JMP    gogo<>(SB)

TEXT gogo<>(SB), NOSPLIT, $0
   // 将tls保存到CX寄存器
  get_tls(CX)
  // 下面这条指令把当前要运行的g（上面第9行中已经把go_buf中的g放入到了DX中），
  // 放入CX寄存器的g位置即tls[0]这个位置，也就是线程的本地存储中，
  // 这样下次runtime中调用getg时获取的就是这个g
  MOVQ   DX, g(CX)
  MOVQ   DX, R14       // set the g register
  // 把CPU的SP寄存器设置为g.sched.sp这样就完成了栈的切换，从g0切换为g
  MOVQ   gobuf_sp(BX), SP   // restore SP
  // 将ret、ctxt、bp分别存入对应的寄存器，完成了CPU上下文的切换
  MOVQ   gobuf_ret(BX), AX
  MOVQ   gobuf_ctxt(BX), DX
  MOVQ   gobuf_bp(BX), BP
  // 清空sched的值，相关值已经存入到寄存器中，这里清空后可以减少GC的工作量
  MOVQ   $0, gobuf_sp(BX)   // clear to help garbage collector
  MOVQ   $0, gobuf_ret(BX)
  MOVQ   $0, gobuf_ctxt(BX)
  MOVQ   $0, gobuf_bp(BX)
  // 把sched.pc放入BX寄存器
  MOVQ   gobuf_pc(BX), BX
  // JMP把BX的值放入CPU的IP寄存器，所以这时候CPU从该地址开始继续执行指令
  JMP    BX
AX、BX、CX、DX是8086处理器的4个数据寄存器，可以简单认为相当于4个硬件的变量；
上文总体来说，将g存入到tls中（线程的本地存储），设置SP和相关寄存器为g.sched中的字段（SP、ret、ctxt、bp），然后跳转到pc指针位置执行指令
1.6 G的退出处理协程栈的退出需要分为两种情况，即运行main函数的主协程和普通的用户协程；
主协程的fn任务函数位于proc.go中的main函数中，对于主协程g.shched.pc指向的也是这个位置，这里会调用用户的mian函数（main_main），main_main运行完毕后，会调用exit(0)直接退出，而不会跑到goexit函数中。

// runtime/proc.go 中的main函数
// The main goroutine.
func main() {
  g := getg()

.................
  fn := main_main // make an indirect call, as the linker doesn't know the address of the main package when laying down the runtime
  fn()
..................
..................
  exit(0)
..................
}
用户协程因为将goexit作为协程栈栈底，所以当执行完协程任务函数时，会执行goexit函数，goexit是一段汇编指令：

// The top-most function running on a goroutine
// returns to goexit+PCQuantum.
TEXT runtime·goexit(SB),NOSPLIT|TOPFRAME,$0-0
  BYTE   $0x90  // NOP
  CALL   runtime·goexit1(SB)    // does not return
  // traceback from goexit1 must hit code range of goexit
  BYTE   $0x90  // NOP
这里直接调用goexit1，goexit1位于runtime/proc.go中

// Finishes execution of the current goroutine.
func goexit1() {
  if raceenabled {
     racegoend()
  }
  if trace.enabled {
     traceGoEnd()
  }
  mcall(goexit0)
}
通过mcall调用goexit0，mcall是一段汇编代码它的作用是把执行的栈切换到g0的栈

TEXT runtime·mcall<ABIInternal>(SB), NOSPLIT, $0-8
  MOVQ   AX, DX // DX = fn

  // save state in g->sched
  // mcall返回地址放入BX中
  MOVQ   0(SP), BX  // caller's PC
  // 下面部分是保存g的执行上下文,pc、sp、bp
  // g.shced.pc = BX
  MOVQ   BX, (g_sched+gobuf_pc)(R14)
  LEAQ   fn+0(FP), BX   // caller's SP
  MOVQ   BX, (g_sched+gobuf_sp)(R14)
  MOVQ   BP, (g_sched+gobuf_bp)(R14)

  // switch to m->g0 & its stack, call fn
  // 将g.m保存到BX寄存器中
  MOVQ   g_m(R14), BX
  // 这段代码意思是从m结构体中获取g0字段保存到SI中
  MOVQ   m_g0(BX), SI   // SI = g.m.g0
  CMPQ   SI, R14    // if g == m->g0 call badmcall
  // goodm中完成了从g的栈切换到g0的栈
  JNE    goodm
  JMP    runtime·badmcall(SB)
goodm:
  MOVQ   R14, AX       // AX (and arg 0) = g
  MOVQ   SI, R14       // g = g.m.g0
  get_tls(CX)       // Set G in TLS
  MOVQ   R14, g(CX)
  MOVQ   (g_sched+gobuf_sp)(R14), SP    // sp = g0.sched.sp
  PUSHQ  AX // open up space for fn's arg spill slot
  MOVQ   0(DX), R12
  // 这里意思是调用goexit0(g)
  CALL   R12       // fn(g)
  POPQ   AX
  JMP    runtime·badmcall2(SB)
  RET
goexit0代码位于runtime/proc.go中，他主要完成最后的清理工作：
1、把g的状态从——Gruning变为Gdead
2、清空g的一些字段
3、接触g与m的绑定关系，即g.m = nil；m.currg = nil
4、把g放入p的freeg队列中，下次创建g可以直接获取，而不用从内存分配
5、调用schedule进入下一次调度循环

// 这段代码执行在g0的栈上，gp是我们要处理退出的g的结构体指针
// goexit continuation on g0.
func goexit0(gp *g) {
  _g_ := getg() // 获取g0
   // 更改g的状态为_Gdead
  casgstatus(gp, _Grunning, _Gdead)
  if isSystemGoroutine(gp, false) {
     atomic.Xadd(&sched.ngsys, -1)
  }
  // 清空g的一些字段
  gp.m = nil
  locked := gp.lockedm != 0
  gp.lockedm = 0
  _g_.m.lockedg = 0
  gp.preemptStop = false
  gp.paniconfault = false
  gp._defer = nil // should be true already but just in case.
  gp._panic = nil // non-nil for Goexit during panic. points at stack-allocated data.
  gp.writebuf = nil
  gp.waitreason = 0
  gp.param = nil
  gp.labels = nil
  gp.timer = nil

  if gcBlackenEnabled != 0 && gp.gcAssistBytes > 0 {
     // Flush assist credit to the global pool. This gives
     // better information to pacing if the application is
     // rapidly creating an exiting goroutines.
     assistWorkPerByte := float64frombits(atomic.Load64(&gcController.assistWorkPerByte))
     scanCredit := int64(assistWorkPerByte * float64(gp.gcAssistBytes))
     atomic.Xaddint64(&gcController.bgScanCredit, scanCredit)
     gp.gcAssistBytes = 0
  }
   // 接触g与m的绑定关系
  dropg()

  if GOARCH == "wasm" { // no threads yet on wasm
     gfput(_g_.m.p.ptr(), gp)
     schedule() // never returns
  }

  if _g_.m.lockedInt != 0 {
     print("invalid m->lockedInt = ", _g_.m.lockedInt, "\n")
     throw("internal lockOSThread error")
  }
  // 将g加入p的空闲队列
  gfput(_g_.m.p.ptr(), gp)
  if locked {
     // The goroutine may have locked this thread because
     // it put it in an unusual kernel state. Kill it
     // rather than returning it to the thread pool.

     // Return to mstart, which will release the P and exit
     // the thread.
     if GOOS != "plan9" { // See golang.org/issue/22227.
        gogo(&_g_.m.g0.sched)
     } else {
        // Clear lockedExt on plan9 since we may end up re-using
        // this thread.
        _g_.m.lockedExt = 0
     }
  }
  // 执行下一轮调度
  schedule()
}
 
2 P源码部分3.2.1 P的结构
// runtime/runtime2.go

type p struct {
   // 全局变量allp中的索引位置
  id          int32
  // p的状态标识
  status      uint32 // one of pidle/prunning/...
  link        puintptr
  // 调用schedule的次数，每次调用schedule这个值会加1
  schedtick   uint32     // incremented on every scheduler call
  // 系统调用的次数，每次进行系统调用加1
  syscalltick uint32     // incremented on every system call
  // 用于sysmon协程记录被监控的p的系统调用时间和运行时间
  sysmontick  sysmontick // last tick observed by sysmon
  // 指向绑定的m，p如果是idle状态这个值为nil
  m           muintptr   // back-link to associated m (nil if idle)
  // 用于分配微小对象和小对象的一个块的缓存空间，里面有各种不同等级的span
  mcache      *mcache
  // 一个chunk大小（512kb）的内存空间，用来对堆上内存分配的缓存优化达到无锁访问的目的
  pcache      pageCache
  raceprocctx uintptr

  deferpool    [5][]*_defer // pool of available defer structs of different sizes (see panic.go)
  deferpoolbuf [5][32]*_defer

  // Cache of goroutine ids, amortizes accesses to runtime·sched.goidgen.
  // 可以分配给g的id的缓存，每次会一次性申请16个
  goidcache    uint64
  goidcacheend uint64

  // Queue of runnable goroutines. Accessed without lock.
  // 本地可运行的G队列的头部和尾部，达到无锁访问
  runqhead uint32
  runqtail uint32
  // 本地可运行的g队列，是一个使用数组实现的循环队列
  runq     [256]guintptr
  // 下一个待运行的g，这个g的优先级最高
  // 如果当前g运行完后还有剩余可用时间，那么就应该运行这个runnext的g
  runnext guintptr

  // Available G's (status == Gdead)
  // p上的空闲队列列表
  gFree struct {
     gList
     n int32
  }

  ............
   // 用于内存对齐
  _ uint32 // Alignment for atomic fields below
.......................
   // 是否被抢占
  preempt bool

  // Padding is no longer needed. False sharing is now not a worry because p is large enough
  // that its size class is an integer multiple of the cache line size (for any of our architectures).
}
通过这里的结构可以看出，虽然P叫做逻辑处理器Processor，实际上它更多是资源的管理者，其中包含了可运行的g队列资源、内存分配的资源、以及对调度循环、系统调用、sysmon协程的相关记录。通过P的资源管理来尽量实现无锁访问，提升应用性能。
 
2.2 P的状态当程序刚开始运行进行初始化时，所有的P都处于_Pgcstop状态，随着的P的初始化（runtime.procresize），会被设置为_Pidle状态。
当M需要运行时会调用runtime.acquirep来使P变为_Prunning状态，并通过runtime.releasep来释放，重新变为_Pidele。
当G执行时需要进入系统调用，P会被设置为_Psyscall，如果这个时候被系统监控抢夺（runtime.retake），则P会被重新修改为_Pidle。
如果在程序中发生GC，则P会被设置为_Pgcstop，并在runtime.startTheWorld时重新调整为_Prunning。
（这部分文字来自《Go程序员面试宝典》，图片来自这里）
2.3 P的创建P的初始化是在schedinit函数中调用的，schedinit函数是在runtime的汇编启动代码里调用的。

...........................
CALL    runtime·args(SB)
CALL   runtime·osinit(SB)
CALL   runtime·schedinit(SB)
...........................
shcedinit中通过调用procresize进行P的分配。P的个数默认等于CPU核数，如果设置了GOMAXPROCS环境变量，则会采用设置的值来确定P的个数。所以runtime.GOMAXPROCS是限制的并行线程数量，而不是系统线程即M的总数，M是按需创建。

func schedinit() {
.................
  lock(&sched.lock)
  sched.lastpoll = uint64(nanotime())
  procs := ncpu
  if n, ok := atoi32(gogetenv("GOMAXPROCS")); ok && n > 0 {
     procs = n
  }
  if procresize(procs) != nil {
     throw("unknown runnable goroutine during bootstrap")
  }
  unlock(&sched.lock)

  // World is effectively started now, as P's can run.
  worldStarted()
  .....................
}
上面获取ncpu的个数，然后传递给procresize函数。
无论是初始化时的分配，还是后期调整，都是通过procresize来创建p以及初始化

func procresize(nprocs int32) *p {
.............................
  old := gomaxprocs
......................
  if nprocs > int32(len(allp)) {
     // Synchronize with retake, which could be running
     // concurrently since it doesn't run on a P.
     lock(&allpLock)
     if nprocs <= int32(cap(allp)) {
         // 如果需要的p小于allp这个全局变量（切片）的cap能力，取其中的一部分
        allp = allp[:nprocs]
     } else {
         // 否则创建nprocs数量的p，并把allp的中复制给nallp
        nallp := make([]*p, nprocs)
        // Copy everything up to allp's cap so we
        // never lose old allocated Ps.
        copy(nallp, allp[:cap(allp)])
        allp = nallp
     }
....................................
     unlock(&allpLock)
  }

  // 进行p的初始化
  for i := old; i < nprocs; i++ {
     pp := allp[i]
     if pp == nil {
        pp = new(p)
     }
     pp.init(i)
     atomicstorep(unsafe.Pointer(&allp[i]), unsafe.Pointer(pp))
  }
...............................
  return runnablePs
}
在启动时候会根据CPU核数和runtime.GOMAXPROCS来设置p的个数，并由一个叫做allp的切片来为主，后期可以通过设置GOMAXPROCS来调整P的个数，但是性能消耗很大，会进行STW；
3 M源码部分3.3.1 M的结构M即Machine，代表一个进程中的工作线程，结构体m保存了M自身使用的栈信息、当前正在M上执行的G，以及绑定M的P信息等。
我们来看下m的结构体：

type m struct {
   // 每个m都有一个对应的g0线程，用来执行调度代码，
   // 当需要执行用户代码的时候，g0会与用户goroutine发生协程栈切换
  g0      *g     // goroutine with scheduling stack
  morebuf gobuf  // gobuf arg to morestack
........................
  // tls作为线程的本地存储
  // 其中可以在任意时刻获取绑定到当前线程上的协程g、结构体m、逻辑处理器p、特殊协程g0等信息
  tls           [tlsSlots]uintptr // thread-local storage (for x86 extern register)
  mstartfn      func()
  // 指向正在运行的goroutine对象
  curg          *g       // current running goroutine
  caughtsig     guintptr // goroutine running during fatal signal
  // 与当前工作线程绑定的p
  p             puintptr // attached p for executing go code (nil if not executing go code)
  nextp         puintptr
  oldp          puintptr // the p that was attached before executing a syscall
  id            int64
  mallocing     int32
  throwing      int32
  // 与禁止抢占相关的字段，如果该字段不等于空字符串，要保持curg一直在这个m上运行
  preemptoff    string // if != "", keep curg running on this m
  // locks也是判断g能否被抢占的一个标识
  locks         int32
  dying         int32
  profilehz     int32
  // spining为true标识当前m正在处于自己找工作的自旋状态，
  // 首先检查全局队列看是否有工作，然后检查network poller，尝试执行GC任务
  //或者偷一部分工作，如果都没有则会进入休眠状态
  spinning      bool // m is out of work and is actively looking for work
  // 表示m正阻塞在note上
  blocked       bool // m is blocked on a note
.........................
  doesPark      bool        // non-P running threads: sysmon and newmHandoff never use .park
  // 没有goroutine需要运行时，工作线程睡眠在这个park成员上
  park          note
  // 记录所有工作线程的一个链表
  alllink       *m // on allm
  schedlink     muintptr
  lockedg       guintptr
  createstack   [32]uintptr // stack that created this thread.
.............................
}
3.2 M的状态M的状态并没有向P和G那样有多个状态常量，它只有自旋和非自旋两种状态

mstart
   |
   v        
+------+       找不到可执行任务           +-------+
|unspin| ----------------------------> |spining| 
|      | <---------------------------- |       |
+------+       找到可执行任务            +-------+
   ^                                      | stopm
   |               wakep                  v
notewakeup <-------------------------  notesleep 
当M没有工作时，它会自旋的来找工作，首先检查全局队列看是否有工作，然后检查network poller，尝试执行GC任务，或者偷一部分工作，如果都没有则会进入休眠状态。当被其他工作线程唤醒，又会进入自旋状态。
3.3 M的创建runtime/proc.go中的newm函数用来新建m，而最终是根据不同的系统，通过系统调用来创建线程。

// newm创建一个新的m，将从fn或者调度程序开始执行
func newm(fn func(), _p_ *p, id int64) {
   // 这里实现m的创建
  mp := allocm(_p_, fn, id)
  mp.doesPark = (_p_ != nil)
  mp.nextp.set(_p_)
  mp.sigmask = initSigmask
  if gp := getg(); gp != nil && gp.m != nil && (gp.m.lockedExt != 0 || gp.m.incgo) && GOOS != "plan9" {
     // 我们处于锁定的M或可能由C启动的线程。此线程的内核状态可能很奇怪（用户可能已将其锁定为此目的）。
     // 我们不想将其克隆到另一个线程中。相反，请求一个已知良好的线程为我们创建线程。
     lock(&newmHandoff.lock)
     if newmHandoff.haveTemplateThread == 0 {
        throw("on a locked thread with no template thread")
     }
     mp.schedlink = newmHandoff.newm
     newmHandoff.newm.set(mp)
     if newmHandoff.waiting {
        newmHandoff.waiting = false
        notewakeup(&newmHandoff.wake)
     }
     unlock(&newmHandoff.lock)
     return
  }
  // 这里分配真正的的操作系统线程
  newm1(mp)
}
allocm函数中实现m的创建，以及对应的g0协程的设置

func allocm(_p_ *p, fn func(), id int64) *m {
   // 获取当前运行的g
  _g_ := getg()
  // 将_g_对应的m的locks加1，防止被抢占
  acquirem() // disable GC because it can be called from sysmon
  if _g_.m.p == 0 {
     acquirep(_p_) // temporarily borrow p for mallocs in this function
  }

  // 检查是有有空闲的m可以释放，主要目的是释放m上的g0占用的系统栈
  if sched.freem != nil {
     lock(&sched.lock)
     var newList *m
     for freem := sched.freem; freem != nil; {
        if freem.freeWait != 0 {
           next := freem.freelink
           freem.freelink = newList
           newList = freem
           freem = next
           continue
        }
        // stackfree must be on the system stack, but allocm is
        // reachable off the system stack transitively from
        // startm.
        systemstack(func() {
           stackfree(freem.g0.stack)
        })
        freem = freem.freelink
     }
     sched.freem = newList
     unlock(&sched.lock)
  }
   // 创建一个m结构体
  mp := new(m)
  mp.mstartfn = fn // 将fn设置为m启动后执行的函数
  mcommoninit(mp, id)

  // In case of cgo or Solaris or illumos or Darwin, pthread_create will make us a stack.
  // Windows and Plan 9 will layout sched stack on OS stack.
  if iscgo || mStackIsSystemAllocated() {
     mp.g0 = malg(-1)
  } else {
      // 设置m对应的g0，并设置对应大小的g0协程栈，g0是8kb
     mp.g0 = malg(8192 * sys.StackGuardMultiplier)
  }
  // 设置g0对应的m
  mp.g0.m = mp

  if _p_ == _g_.m.p.ptr() {
     releasep()
  }
  // 解除_g_的m的禁止抢占状态。
  releasem(_g_.m)

  return mp
}
为什么m.locks加1可以禁止抢占，防止GC；因为判断是否可以抢占，其中一个因素就是要m.locks=0

func canPreemptM(mp *m) bool {
  return mp.locks == 0 && mp.mallocing == 0 && mp.preemptoff == "" && mp.p.ptr().status == _Prunning
}
allocm函数实现了m的创建，但是这只是runtime层面的一个数据结构，还并没有在系统中有真正的线程。再来看newm1函数：

func newm1(mp *m) {
..............
  execLock.rlock() // Prevent process clone.
  // 创建一个系统线程，并且传入该 mp 绑定的 g0 的栈顶指针
  // 让系统线程执行 mstart 函数，后面的逻辑都在 mstart 函数中
  newosproc(mp)
  execLock.runlock()
}
实际是通过newostproc来创建系统线程；
可以看到这个函数在不同的系统中有不同的实现，我们主要看linux系统，即os_linux.go文件代码：

func newosproc(mp *m) {
  stk := unsafe.Pointer(mp.g0.stack.hi)
.........................
  var oset sigset
  sigprocmask(_SIG_SETMASK, &sigset_all, &oset)
  ret := clone(cloneFlags, stk, unsafe.Pointer(mp), unsafe.Pointer(mp.g0), unsafe.Pointer(funcPC(mstart)))
  sigprocmask(_SIG_SETMASK, &oset, nil)
.........................
}
在linux平台，是通过clone这个系统调用来创建的线程；值得注意的是，这个系统线程的栈是在堆上；因为其中的stk指向mp.go.stack.hi，所以g0的堆栈也就是这个系统线程的堆栈。
3.4 M的休眠M的自旋指的是m.spining为true，这个时候它会在P的本地G队列、全局G队列、nerpoller、偷其他P的G，一直循环找可运行的G的过程中。
自旋状态用 m.spinning 和 sched.nmspinning 表示。其中 m.spinning 表示当前的M是否为自旋状态，sched.nmspinning 表示runtime中一共有多少个M在自旋状态。
当自旋了一段时间后，发现仍然找不到工作，就会进入stopm函数中，使M对应的线程进行休眠。

func stopm() {
  _g_ := getg()
.....................
  lock(&sched.lock)
  // 首先将m放到全局空闲链表中，这里要加锁访问全局链表
  mput(_g_.m)
  unlock(&sched.lock)
  // 进入睡眠状态
  mPark()
  // 将m与p解绑
  acquirep(_g_.m.nextp.ptr())
  _g_.m.nextp = 0
}

func mPark() {
  g := getg()
  for {
      // 使工作线程休眠在park字段上
     notesleep(&g.m.park)
     noteclear(&g.m.park)
     if !mDoFixup() {
        return
     }
  }
}
实际将线程进行休眠的代码，是通过汇编语言进行Futex系统调用来事项的。Futex机制是Linux提供的一种用户态和内核态混合的同步机制。Linux底层也是使用futex机制实现的锁。

    //uaddr指向一个地址，val代表这个地址期待的值，当*uaddr==val时，才会进行wait
    int futex_wait(int *uaddr, int val);
    //唤醒n个在uaddr指向的锁变量上挂起等待的进程
    int futex_wake(int *uaddr, int n);
可以看到在futex_wait中当一个地址等于某个期待值时，就会进行wait；所以当m中的park的key等于某个值时则进入休眠状态。
3.5 M的唤醒M的唤醒是在wakep函数中处理的。当一个新的goroutine创建或者有多个goroutine进入_Grunnable状态时，会先判断是否有自旋的M，如果有则不会唤醒其他的M而使用自旋的M，当没有自旋的M，但m空闲队列中有空闲的M则会唤醒M，否则会创建一个新的M

// Tries to add one more P to execute G's.
// Called when a G is made runnable (newproc, ready).
func wakep() {
  if atomic.Load(&sched.npidle) == 0 {
     return
  }
  // be conservative about spinning threads
  // 如果有其他的M处于自旋状态，那么就不管了，直接返回,因为自旋的M会拼命找G来运行的
  if atomic.Load(&sched.nmspinning) != 0 || !atomic.Cas(&sched.nmspinning, 0, 1) {
     return
  }
  startm(nil, true)
}
startm先判断是否有空闲的P，如果没有则返回，如果有空闲的P，在尝试看看有没有空闲的M，有则唤醒该M来工作。如果没有空闲M，则新建一个M，然后也进入唤醒操作。

func startm(_p_ *p, spinning bool) {
  // 禁止抢占，防止GC垃圾回收
  mp := acquirem()
  lock(&sched.lock)
  // 如果P为nil，则尝试获取一个空闲P
  if _p_ == nil {
     _p_ = pidleget()
     if _p_ == nil { // 没有空闲的P，则解除禁止抢占，直接返回
        unlock(&sched.lock)
        if spinning {
           if int32(atomic.Xadd(&sched.nmspinning, -1)) < 0 {
              throw("startm: negative nmspinning")
           }
        }
        releasem(mp)
        return
     }
  }
  // 获取一个空闲的M
  nmp := mget()
  if nmp == nil {
     // 如果没有空闲的m则新建一个
     id := mReserveID()
     unlock(&sched.lock)

     var fn func()
     if spinning {
        // The caller incremented nmspinning, so set m.spinning in the new M.
        fn = mspinning
     }
     newm(fn, _p_, id)
     // Ownership transfer of _p_ committed by start in newm.
     // Preemption is now safe.
     releasem(mp)
     return
  }
  unlock(&sched.lock)
......................
  //标记该M是否在自旋
  nmp.spinning = spinning
  // 暂存P
  nmp.nextp.set(_p_)
  // 唤醒M
  notewakeup(&nmp.park)
  // Ownership transfer of _p_ committed by wakeup. Preemption is now
  // safe.
  releasem(mp)
}
唤醒线程的底层操作同样是依赖futex机制

    //唤醒n个在uaddr指向的锁变量上挂起等待的进程
    int futex_wake(int *uaddr, int n);
 
启动过程4.1 Go scheduler结构在runtime中全局变量sched代表全局调度器，数据结构为schedt结构体，保存了调度器的状态信息、全局可运行G队列

type schedt struct {
  // 用来为goroutine生成唯一id，需要以原子访问形式进行访问
  // 放在struct顶部，以便在32位系统上可以进行对齐
  goidgen   uint64
...................
  lock mutex
   // 空闲的m组成的链表
  midle        muintptr // idle m's waiting for work
  // 空闲的工作线程数量
  nmidle       int32    // number of idle m's waiting for work
  // 空闲的且被lock的m的数量
  nmidlelocked int32    // number of locked m's waiting for work
  mnext        int64    // number of m's that have been created and next M ID
  // 表示最多能够创建的工作线程数量
  maxmcount    int32    // maximum number of m's allowed (or die)
  nmsys        int32    // number of system m's not counted for deadlock
  nmfreed      int64    // cumulative number of freed m's
   // 整个goroutine的数量，能够自动保持更新
  ngsys uint32 // number of system goroutines; updated atomically
   // 由空闲的p结构体对象组成的链表
  pidle      puintptr // idle p's
  // 空闲的p结构体对象的数量
  npidle     uint32
  // 自旋的m的数量
  nmspinning uint32 // See "Worker thread parking/unparking" comment in proc.go.

  // Global runnable queue.
  // 全局的的g的队列
  runq     gQueue
  runqsize int32

  disable struct {
     // user disables scheduling of user goroutines.
     user     bool
     runnable gQueue // pending runnable Gs
     n        int32  // length of runnable
  }

  // Global cache of dead G's.
  // 空闲的g队列，这里面g的状态为_Gdead
  gFree struct {
     lock    mutex
     stack   gList // Gs with stacks
     noStack gList // Gs without stacks
     n       int32
  }
.................
   // 空闲的m队列
  freem *m
.....................
   // 上次修改gomaxprocs的时间
  procresizetime int64 // nanotime() of last change to gomaxprocs
......................
}
这里面大部分是记录一些空闲的g、m、p等，在runtime2.go中还有很多相关的全局变量：

// runtime/runtime2.go
var (
   // 保存所有的m
  allm       *m
  // p的最大个数，默认等于cpu核数
  gomaxprocs int32
  // cpu的核数，程序启动时会调用osinit获取ncpu值
  ncpu       int32
  // 调度器结构体对象，记录了调度器的工作状态
  sched      schedt
  newprocs   int32

  allpLock mutex
  // 全局的p队列
  allp []*p
)

// runtime/proc.go
var (
   // 代表进程主线程的m0对象
  m0           m
  // m0的g0
  g0           g
  // 全局的mcache对象，管理各种类型的span队列
  mcache0      *mcache
  raceprocctx0 uintptr
)
 
2 启动流程调度器的初始化和启动调度循环是在进程初始化是处理的，整个进程初始化流程如下：
Go 进程的启动是通过汇编代码进行的，入口函数在asm_amd64.s这个文件中的runtime.rt0_go部分代码；

// runtime·rt0_go

// 程序刚启动的时候必定有一个线程启动（主线程）
// 将当前的栈和资源保存在g0
// 将该线程保存在m0
// tls: Thread Local Storage
// set the per-goroutine and per-mach "registers"
get_tls(BX)
LEAQ    runtime·g0(SB), CX
MOVQ    CX, g(BX)
LEAQ    runtime·m0(SB), AX

// m0和g0互相绑定
// save m->g0 = g0
MOVQ    CX, m_g0(AX)
// save m0 to g0->m
MOVQ    AX, g_m(CX)
// 处理args
CALL    runtime·args(SB) 
// os初始化， os_linux.go
CALL    runtime·osinit(SB) 
// 调度系统初始化, proc.go
CALL    runtime·schedinit(SB) 

// 创建一个goroutine，然后开启执行程序
// create a new goroutine to start program
MOVQ    $runtime·mainPC(SB), AX        // entry
PUSHQ    AX
PUSHQ    $0            // arg size
CALL    runtime·newproc(SB)
POPQ    AX
POPQ    AX

// start this M
// 启动线程，并且启动调度系统
CALL    runtime·mstart(SB)
可以看到通过汇编代码：
1、将m0与g0互相绑定，然后调用runtime.osinit函数，这个函数不同的操作系统有不同的实现；
2、然后调用runtime.schedinit进行调度系统的初始化；
3、然后创建主协程；主goroutine创建完成后被加入到p的运行队列中，等待调度；
4、在g0上启动调用runtime.mstart启动调度循环，首先可以被调度执行的就是主goroutine，然后主协程获得运行的cpu则执行runtime.main进而执行到用户代码的main函数。
 
初始化过程和堆栈图可以参考下图：
堆栈上，g0、m0、p0与主协程关系如图所示：
3 调度器初始化调度器初始化

func schedinit() {
................
   // g0
  _g_ := getg()
  if raceenabled {
     _g_.racectx, raceprocctx0 = raceinit()
  }
   // 最多启动10000个工作线程
  sched.maxmcount = 10000

  // The world starts stopped.
  worldStopped()

  moduledataverify()
  // 初始化协程堆栈，包括专门分配小栈的stackpool和分配大栈的stackLarge
  stackinit()
  // 整个堆内存的初始化分配
  mallocinit()
  fastrandinit() // must run before mcommoninit
  // 初始化m0
  mcommoninit(_g_.m, -1)
  cpuinit()       // must run before alginit
  alginit()       // maps must not be used before this call
  modulesinit()   // provides activeModules
  typelinksinit() // uses maps, activeModules
  itabsinit()     // uses activeModules

  sigsave(&_g_.m.sigmask)
  initSigmask = _g_.m.sigmask

  if offset := unsafe.Offsetof(sched.timeToRun); offset%8 != 0 {
     println(offset)
     throw("sched.timeToRun not aligned to 8 bytes")
  }

  goargs()
  goenvs()
  parsedebugvars()
  gcinit()
  // 这部分是初始化p，
  // cpu有多少个核数就初始化多少个p
  lock(&sched.lock)
  sched.lastpoll = uint64(nanotime())
  procs := ncpu
  if n, ok := atoi32(gogetenv("GOMAXPROCS")); ok && n > 0 {
     procs = n
  }
  if procresize(procs) != nil {
     throw("unknown runnable goroutine during bootstrap")
  }
  unlock(&sched.lock)

  // World is effectively started now, as P's can run.
  worldStarted()
}
4 启动调度系统调度系统时在runtime.mstart0函数中启动的。这个函数是在m0的g0上执行的。

func mstart0() {
   // 这里获取的是g0在系统栈上执行
  _g_ := getg()
.............
  mstart1()
.............
}

func mstart1(dummy int32) {
   _g_ := getg()
   // 确保g是系统栈上的g0
   // 调度器只在g0上执行
   if _g_ != _g_.m.g0 {
       throw("bad runtime·mstart")
   }
   ...
   // 初始化m，主要是设置线程的备用信号堆栈和信号掩码
   minit()
   // 如果当前g的m是初始m0，执行mstartm0()
   if _g_.m == &m0 {
       // 对于初始m，需要一些特殊处理，主要是设置系统信号量的处理函数
       mstartm0()
   }
   // 如果有m的起始任务函数，则执行，比如 sysmon 函数
   // 对于m0来说，是没有 mstartfn 的
   if fn := _g_.m.mstartfn; fn != nil {
       fn()
   }
   if _g_.m.helpgc != 0 {
       _g_.m.helpgc = 0
       stopm()
   } else if _g_.m != &m0 { // 如果不是m0，需要绑定p
       // 绑定p
       acquirep(_g_.m.nextp.ptr())
       _g_.m.nextp = 0
   }
   // 进入调度循环，永不返回
   schedule()
}
 
5 runtime.main函数当经过初始的调度，主协程获取执行权后，首先进入的就是runtime.main函数：

// The main goroutine.
func main() {
   // 获取 main goroutine
   g := getg()
   ...
   // 在系统栈上运行 sysmon
   systemstack(func() {
       // 分配一个新的m，运行sysmon系统后台监控
       // （定期垃圾回收和调度抢占）
       newm(sysmon, nil)
   })
   ...
   // 确保是主线程
   if g.m != &m0 {
       throw("runtime.main not on m0")
   }
   // runtime 内部 init 函数的执行，编译器动态生成的。
   runtime_init() // must be before defer
   ...
   // gc 启动一个goroutine进行gc清扫
   gcenable()
   ...
   // 执行init函数，编译器动态生成的，
   // 包括用户定义的所有的init函数。
   // make an indirect call,
   // as the linker doesn't know the address of
   // the main package when laying down the runtime
   fn := main_init 
   fn()
   ...
   // 真正的执行main func in package main
   // make an indirect call,
   // as the linker doesn't know the address of
   // the main package when laying down the runtime
   fn = main_main 
   fn()
   ...
   // 退出程序
   exit(0)
   // 为何这里还需要for循环？
   // 下面的for循环一定会导致程序崩掉，这样就确保了程序一定会退出
   for {
       var x *int32
       *x = 0
   }
}
runtime.main函数中需要注意的是在系统栈上创建了一个新的m，来执行sysmon协程，这个协程是用来定期执行垃圾回收和调度抢占。
其中可以看到首先获取了main_init函数，来执行runtime包中的init函数，然后是获取main_main来执行用户的main函数。
接着main函数执行完成后，调用exit让主进程退出，如果进程没有退出，就让for循环一直访问非法地址，让操作系统把进程杀死，这样来确保进程一定会退出。
 
协程的调度策略调度循环启动之后，便会进入一个无限循环中，不断的执行schedule->execute->gogo->goroutine任务->goexit->goexit1->mcall->goexit0->schedule；
其中调度的过程是在m的g0上执行的，而goroutine任务->goexit->goexit1->mcall则是在goroutine的堆栈空间上执行的。
1 调度策略其中schedule函数处理具体的调度策略；execute函数执行一些具体的状态转移、协程g与结构体m之间的绑定；gogo函数是与操作系统相关的函数，执行汇编代码完成栈的切换以及CPU寄存器的恢复。
先来看下schedule的代码：

func schedule() {
   _g_ := getg()
   ...
top:
   // 如果当前GC需要停止整个世界（STW), 则调用gcstopm休眠当前的M
   if sched.gcwaiting != 0 {
       // 为了STW，停止当前的M
       gcstopm()
       // STW结束后回到 top
       goto top
   }
   ...
   var gp *g
   var inheritTime bool
   ...
   if gp == nil {
       // 为了防止全局队列中的g永远得不到运行，所以go语言让p每执行61调度，
               // 就需要优先从全局队列中获取一个G到当前P中，并执行下一个要执行的G
       if _g_.m.p.ptr().schedtick%61 == 0 && sched.runqsize > 0 {
           lock(&sched.lock)
           gp = globrunqget(_g_.m.p.ptr(), 1)
           unlock(&sched.lock)
       }
   }
   if gp == nil {
       // 从p的本地队列中获取
       gp, inheritTime = runqget(_g_.m.p.ptr())
       if gp != nil && _g_.m.spinning {
           throw("schedule: spinning with local work")
       }
   }
   if gp == nil {
       // 想尽办法找到可运行的G，找不到就不用返回了
       gp, inheritTime = findrunnable() // blocks until work is available
   }
   ...
   // println("execute goroutine", gp.goid)
   // 找到了g，那就执行g上的任务函数
   execute(gp, inheritTime)
}
findrunnalbe中首先还是从本地队列中检查，然后从全局队列中寻找，再从就绪的网络协程，如果这几个没有就去其他p的本地队列偷一些任务。

func findrunnable() (gp *g, inheritTime bool) {
  _g_ := getg()

top:
............................
  // 本地队列中检查
  if gp, inheritTime := runqget(_p_); gp != nil {
     return gp, inheritTime
  }
  // 从全局队列中寻找
  if sched.runqsize != 0 {
     lock(&sched.lock)
     gp := globrunqget(_p_, 0)
     unlock(&sched.lock)
     if gp != nil {
        return gp, false
     }
  }
  // 从就绪的网络协程中查找
  if netpollinited() && atomic.Load(&netpollWaiters) > 0 && atomic.Load64(&sched.lastpoll) != 0 {
     if list := netpoll(0); !list.empty() { // non-blocking
        gp := list.pop()
        injectglist(&list)
        casgstatus(gp, _Gwaiting, _Grunnable)
        if trace.enabled {
           traceGoUnpark(gp, 0)
        }
        return gp, false
     }
  }

   // 进入自旋状态
   procs := uint32(gomaxprocs)
   if _g_.m.spinning || 2*atomic.Load(&sched.nmspinning) < procs-atomic.Load(&sched.npidle) {
      if !_g_.m.spinning {
         _g_.m.spinning = true
         atomic.Xadd(&sched.nmspinning, 1)
      }
       // 从其他p的本地队列中偷工作
      gp, inheritTime, tnow, w, newWork := stealWork(now)
..............................
   }
}
整个调度的优先级如下：
 
2 调度时机5.1讲了调度的策略，什么时机发生调度呢，主要有三种方式，主动调度、被动调度、抢占式调度。
2.1 主动调度协程可以选择主动让渡自己的执行权利，大多数情况下不需要这么做，但通过runtime.Goched可以做到主动让渡。

func Gosched() {
  checkTimeouts()
  mcall(gosched_m)
}

// 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")
  }
  // 更改g的运行状态
  casgstatus(gp, _Grunning, _Grunnable)
  // 接触g和m的绑定关系
  dropg()
  // 将g放入全局队列中
  lock(&sched.lock)
  globrunqput(gp)
  unlock(&sched.lock)

  schedule()
}
2.2 被动调度大部分情况下的调度都是被动调度，当协程在休眠、channel通道阻塞、网络IO阻塞、执行垃圾回收时会暂停，被动调度可以保证最大化利用CPU资源。被动调度是协程发起的操作，所以调度时机相对明确。
首先从当前栈切换到g0协程，被动调度不会将G放入全局运行队列，所以被动调度需要一个额外的唤醒机制。
这里面涉及的函数主要是gopark和ready函数。
gopark函数用来完成被动调度，有_Grunning变为_Gwaiting状态；

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
  }
  // 禁止抢占和GC
  mp := acquirem()
  gp := mp.curg // 过去当前m上运行的g
  status := readgstatus(gp)
  if status != _Grunning && status != _Gscanrunning {
     throw("gopark: bad g status")
  }
  // 设置相关的wait字段
  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()
   // 变更g的状态
  casgstatus(gp, _Grunning, _Gwaiting)
  // 接触g与m的绑定关系
  dropg()
   // 根据被动调度不同原因，执行不同的waitunlockf函数
  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()
}
当协程要被唤醒时，会进入ready函数中，更改协程状态由_Gwaiting变更为_Grunnable，放入本地运行队列等待被调度。

func ready(gp *g, traceskip int, next bool) {
..............
  status := readgstatus(gp)

  // Mark runnable.
  _g_ := getg()
  mp := acquirem() // disable preemption because it can be holding p in a local var
...............
  // 变更状态之后，放入p的局部运行队列中
  casgstatus(gp, _Gwaiting, _Grunnable)
  runqput(_g_.m.p.ptr(), gp, next)
  wakep()
  releasem(mp)
}
2.3 抢占式调度如果一个g运行时间过长就会导致其他g难以获取运行机会，当进行系统调用时也存在会导致其他g无法运行情况；当出现这两种情况时，为了让其他g有运行机会，则会进行抢占式调度。
是否进行抢占式调度主要是在sysmon协程上判断的。sysmon协程是一个不需要p的协程，它作用主要是运行后台监控，进行netpool（获取fd事件）、retake（抢占式调度）、forcegc（按时间强制执行GC）、scavenge heap（强制释放闲置堆内存，减少内存占用）
 
其中与抢占式调度相关的就是retake函数，
这里我们需要知道的是连续运行10ms则认为时间过长，进行抢占
发生系统调用时，当前正在工作的线程会陷入等待状态，等待内部完成系统调用并返回，所以也需要让渡执行权给其他g，但这里当只有满足几种情况才会进行调度：
1、如果p的运行队列中有等待运行的g则抢占
2、如果没有空闲的p则进行抢占
3、系统调用时间超过10ms则进行抢占

func retake(now int64) uint32 {
  n := 0
  lock(&allpLock)
  // 遍历所有的P
  for i := 0; i < len(allp); i++ {
     _p_ := allp[i]
     if _p_ == nil {
        // This can happen if procresize has grown
        // allp but not yet created new Ps.
        continue
     }
     pd := &_p_.sysmontick
     s := _p_.status
     sysretake := false
     
     if s == _Prunning || s == _Psyscall {
        // 判断如果g的运行时间过长则抢占
        t := int64(_p_.schedtick)
        if int64(pd.schedtick) != t {
           pd.schedtick = uint32(t)
           pd.schedwhen = now
        } else if pd.schedwhen+forcePreemptNS <= now {
            // 如果连续运行10ms则进行抢占
           preemptone(_p_)
           sysretake = true
        }
     }
     // 针对系统调用情况进行抢占
     // 如果p的运行队列中有等待运行的g则抢占
     // 如果没有空闲的p则进行抢占
     // 系统调用时间超过10ms则进行抢占
     if s == _Psyscall {
        // Retake P from syscall if it's there for more than 1 sysmon tick (at least 20us).
        t := int64(_p_.syscalltick)
        if !sysretake && int64(pd.syscalltick) != t {
           pd.syscalltick = uint32(t)
           pd.syscallwhen = now
           continue
        }
        // On the one hand we don't want to retake Ps if there is no other work to do,
        // but on the other hand we want to retake them eventually
        // because they can prevent the sysmon thread from deep sleep.
        if runqempty(_p_) && atomic.Load(&sched.nmspinning)+atomic.Load(&sched.npidle) > 0 && pd.syscallwhen+10*1000*1000 > now {
           continue
        }
        // Drop allpLock so we can take sched.lock.
        unlock(&allpLock)
        // Need to decrement number of idle locked M's
        // (pretending that one more is running) before the CAS.
        // Otherwise the M from which we retake can exit the syscall,
        // increment nmidle and report deadlock.
        incidlelocked(-1)
        if atomic.Cas(&_p_.status, s, _Pidle) {
           if trace.enabled {
              traceGoSysBlock(_p_)
              traceProcStop(_p_)
           }
           n++
           _p_.syscalltick++
           handoffp(_p_)
        }
        incidlelocked(1)
        lock(&allpLock)
     }
  }
  unlock(&allpLock)
  return uint32(n)
}
在进行抢占式调度，Go还涉及到利用操作系统信号方式来进行抢占，这里就不在介绍，感兴趣可以自己去研究。
 
另外，本文图片没有一张原创，画图非常耗费时间，我没有那么多时间，所以只能到处借用大家的图片，侵权请联系。
参考资料
Go语言的调度模型：https://www.cnblogs.com/lvpengbo/p/13973906.html
深度揭秘Go语言 sync.Pool：https://www.cnblogs.com/qcrao-2018/p/12736031.html
https://toutiao.io/posts/2gic8x/preview
万字长文深入浅出go runtime：https://zhuanlan.zhihu.com/p/95056679
深入go runtime的调度：https://zboya.github.io/post/go_scheduler/
字节Go面试：https://leetcode-cn.com/circle/discuss/A0YstA/
golang调度学习-调度过程：https://blog.csdn.net/diaosssss/article/details/93066804
Go调度器中的三种结构：G、P、M：https://blog.csdn.net/chenxun_2010/article/details/103696394
Go语言的调度模型：https://www.cnblogs.com/lvpengbo/p/13973906.html
Go GMP的调度模型：https://zhuanlan.zhihu.com/p/413970952
详细剖析Go语言调度模型的设计：https://www.elecfans.com/d/1670400.html
Go的核心goroutine sysmon：https://blog.csdn.net/RA681t58CJxsgCkJ31/article/details/108633220
一文教你搞懂Go中栈操作：https://zhuanlan.zhihu.com/p/364813527
详解Go语言调度循环代码实现：https://www.luozhiyun.com/archives/448
goroutine的创建、休眠与恢复：https://zhuanlan.zhihu.com/p/386595432

 