关于golang:深入理解Go协程设计与调度原理上

协程是更轻量的用户态线程，是 Go 语言的外围。那么如何去调度这些协程何时去执行、如何更正当的调配操作系统资源，须要一个设计良好的调度器来反对。
什么才是一个好的调度器？能在适当的机会将适合的协程调配到适合的地位，保障偏心和效率。

func main() {
    for i := 0; i < 10; i++ {go func() {fmt.Println(i)
        }()}
    time.Sleep(1 * time.Second)
}

这段代码中，咱们开启了 10 个协程，每个协程打印去打印 i 这个变量。因为这 10 个协程的调度机会并不固定，所以等到协程被调度执行的时候才会去取循环中变量 i 的值。

咱们写的这段代码，每个咱们开启的协程都是一个计算工作，这些工作会被提交给 go 的 runtime。如果计算工作十分多，有成千上万个，那么这些工作是不可能同时被立即执行的，所以这个计算工作肯定会被先暂存起来，个别的做法是放到内存的队列中期待被执行。

而生产端则是一个 go runtime 保护的一个 调度循环 。调度循环简略来说，就是一直从队列中生产计算工作并执行。这里实质上就是一个生产者 - 消费者模型，实现了用户工作与调度器的解耦。

这里图中的 G 就代表咱们的一个 goroutine 计算工作，M 就代表 操作系统线程

接下来咱们具体解说一下调度策略。

接下面的例子，咱们生产了 10 个计算工作，咱们肯定是要在内存中先把它存起来期待调度器去生产的。那么很显然，最合适的数据结构就是队列，先来先服务。然而这样做是有问题的。当初咱们都是多核多线程模型，消费者必定不止有一个，所以如果多个消费者去生产同一个队列，会呈现线程平安的问题，必须加锁。所有计算工作 G 都必须在 M 上来执行。

在 Go 中，为了解决加锁的问题，将全局队列拆成了多个本地队列，而这个本地队列由一个叫做 P 的构造来治理。

这样一来，每个 M 只须要去先找到一个 P 构造，和 P 构造绑定，而后执行 P 本地队列里的 G 即可，完满的解决了加锁的问题。

然而每个 P 的本地队列长度不可能有限长（目前为 256），设想一下有成千上万个 go routine 的场景，这样很可能导致本地队列无奈包容这么多的 Goroutine，所以 Go 保留了全局队列，用以解决上述情况。

那么为什么本地队列是数组，而全局队列是链表呢？因为全局队列是本地队列的兜底策略，所以全局队列大小必须是有限的，所以必须是一个链表。

全局队列被调配在全局的调度器构造上，只有一份:

type schedt struct {
    ...
    // Global runnable queue.
    runq     gQueue // 全局队列
    runqsize int32  // 全局队列大小
    ...
}

那么本地队列为什么做成数组而不是链表呢？因为操作系统内存治理会将间断的存储空间提前读入缓存（局部性原理），所以数组往往会被都读入到缓存中，对缓存敌对，效率较高；而链表因为在内存中散布是扩散的，往往不会都读入到缓存中，效率较低。所以本地队列综合思考性能与扩展性，还是抉择了数组作为最终实现。

而 Go 又为了实现局部性原理，在 P 中又加了一个 runnext 的构造，这个构造大小为 1，在 runnext 中的 G 永远会被最先调度执行。接下来会讲为什么须要这个 runnext 构造。残缺的生产端数据结构如下：

P 构造的定义：

type p struct {
    ...
    // Queue of runnable goroutines. Accessed without lock.
    runqhead uint32 // 本地队列队头
    runqtail uint32 // 本地队列队尾
    runq     [256]guintptr // 本地队列，大小 256
    runnext guintptr // runnext，大小为 1
    ...
}

每个协程 G 创立进去之后，主线程 m0 会调用 newproc()，这里会先选定以后 m0 上的 P
每个协程 G 都会被尝试先放到 P 中的 runnext，若 runnext 为空，生产完结
若 runnext 满了，则将原来 runnext 中的 G 踢到本地队列中。生产完结
若本地队列也满了，则将本地队列中的 G 拿出一半，加上以后协程 G，这个拼成的构造在源码中叫 batch，会将 batch 一起放到全局队列中，生产完结。这样一来本地队列的空间就不会满了，接下来的生产流程不会被本地队列满而阻塞

所以咱们看到，最终 runnext 中的 G 肯定是最初生产进去的 G，也会被优先被调度去执行。这里是思考到局部性原理，最近创立进去的协程肯定会被最先执行，优先级是最高的。

runqput 的逻辑：

func runqput(_p_ *p, gp *g, next bool) {

    // 先尝试放到 runnext 中
    if randomizeScheduler && next && fastrand()%2 == 0 {next = false}

    if next {
    retryNext:
        // 拿到老的 runnext 值。oldnext := _p_.runnext
        // 替换以后 runnext 的老的 G 和以后 G 的地址，相当于将以后 G 放入了 runnext
        if !_p_.runnext.cas(oldnext, guintptr(unsafe.Pointer(gp))) {goto retryNext}
        // 老的 runnext 为空，生产完结
        if oldnext == 0 {return}
        // 老的 runnext 不空，则将被替换掉的 runnext 赋值给 gp，而后上面会 set 到本地队列的尾部
        gp = oldnext.ptr()}

retry:
    // 尝试放到本地队列
    h := atomic.LoadAcq(&_p_.runqhead) // load-acquire, synchronize with consumers
    t := _p_.runqtail
     // 本地队列没有满，那么 set 进去
    if t-h < uint32(len(_p_.runq)) {_p_.runq[t%uint32(len(_p_.runq))].set(gp)
        atomic.StoreRel(&_p_.runqtail, t+1) // store-release, makes the item available for consumption
        return
    }
    // 如果本地队列不满方才会间接 return；若已满会走到这里，会将本地队列的一半 G 放到全局队列中
    if runqputslow(_p_, gp, h, t) {return}
    // the queue is not full, now the put above must succeed
    goto retry
}

生产端就是一个调度循环，一直的从本地队列和全局队列生产 G、给 G 绑定一个 M、执行 G，而后再次生产 G、给 G 绑定一个 M、执行 G … 那么执行这个调度循环的人是谁呢？答案是 g0，每个 M 上，都有一个 g0，管制本人线程下面的调度循环：

type m struct {
    g0      *g     // goroutine with scheduling stack
    ...
}

g0 是一个非凡的协程。为了给接下来 M 执行计算工作 G 做筹备，g0 须要先帮忙获取一个线程 M，依据随机算法给 M 绑定一个 P，让 P 上的计算工作 G 失去执行，而后正式进入调度循环。整体的调度循环分为四个步骤：

schedule：g0 来执行，解决具体的调度策略，如从 P 的 runnext/ 本地或者全局队列中获取一个 G，而后会调用 execute()
execute：把 G 和 M 绑定，初始化一些字段，调用 gogo()
gogo：和操作系统架构相干，会将待执行的 G 调度到线程 M 上来执行，实现栈的切换
goexit：执行一些清理逻辑，并调用 schedule()从新开始一轮调度循环

即每次调度循环，都会实现 g0 -> G -> g0 的上下文切换。

schedule 是调度循环的外围。因为 P 中的 G 散布在 runnext、本地队列和全局队列中，则须要挨个判断是否有可执行的 G，大体逻辑如下：

先到 P 上的 runnext 看一下是否有 G，若有则间接返回
runnext 为空，则去本地队列中查找，找到了则间接返回
本地队列为空，则去阻塞的去全局队列、网路轮询器、以及其余 P 中查找，始终阻塞直到获取到一个可用的 G 为止

源码实现如下：

func schedule() {_g_ := getg()
    var gp *g
    var inheritTime bool
    ...
    if gp == nil {
        // 每执行 61 次调度循环会看一下全局队列。为了保障偏心，防止全局队列始终无奈失去执行的状况，当全局运行队列中有待执行的 G 时，通过 schedtick 保障有肯定几率会从全局的运行队列中查找对应的 Goroutine；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 的 runnext 和本地队列查找 G
        gp, inheritTime = runqget(_g_.m.p.ptr())
    }
    if gp == nil {
        // 仍找不到，去全局队列中查找。还找不到，要去网络轮询器中查找是否有 G 期待运行；仍找不到，则尝试从其余 P 中窃取 G 来执行。gp, inheritTime = findrunnable() // blocks until work is available
        // 这个函数是阻塞的，执行到这里肯定会获取到一个可执行的 G
    }
    ...
    // 调用 execute，持续调度循环
    execute(gp, inheritTime)
}

其中 schedtick 这里，每执行 61 次的调度循环，就须要去全局队列尝试获取一次。为什么要这样做呢？假如有十万个 G 源源不断的退出到 P 的本地队列中，那么全局队列中的 G 可能永远得不到执行被饿死，所以必须要在从本地队列获取之前有一个判断逻辑，定期从全局队列获取 G 以保障偏心。

与此同时，调度器会将全局队列中的一半 G 都拿过去，放到以后 P 的本地队列中。这样做的目标是，如果下次调度循环到来的时候，就不用去加锁到全局队列中在获取一次 G 了，性能失去了很好的保障。

这里去其余 P 种查找的逻辑也叫 work stealing，即工作窃取。这里也是会应用随机算法，随机抉择一个 P，偷取该 P 中一半的 G 放入以后 G 的本地队列，而后取本地队列尾部的一个 G 拿来执行。

到这里置信大家曾经理解了 GMP 的概念，咱们最终来总结一下：

G：goroutine，代表一个计算工作，由代码和上下文（如以后代码执行的地位、栈信息、状态等）组成
M：machine，零碎线程，想要在 CPU 上执行代码必须有线程，通过零碎调用 clone 创立
P：processor，虚构处理器。M 必须取得 P 能力执行 P 队列中的 G 代码，否则会陷入休眠

以上只是假如 G 失常执行的状况。如果 G 存在阻塞期待（如 channel、零碎调用）等，那么须要将此时此刻的 M 与 P 上的 G 进行解绑，让 M 执行其余 P 上的 G，从而最大化晋升 CPU 利用率。以及从零碎调用中陷入、复原须要触发调度器调度的机会，这部分逻辑会在下一篇文章中做出解说。

欢送对本系列文章感兴趣的读者订阅咱们的公众号，关注博主下次不迷路～

关于golang:深入理解Go协程设计与调度原理上

从 go func 说起

调度策略

生产端

生产端 1.0

生产端 2.0

残缺的生产流程

生产端

schedule

GMP 模型

异样逻辑解决

关注咱们

Just My Socks（注册教程内含优惠码）

关于golang:深入理解Go协程设计与调度原理上

从 go func 说起

调度策略

生产端

生产端 1.0

生产端 2.0

残缺的生产流程

生产端

schedule

GMP 模型

异样逻辑解决

关注咱们

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）