由一个问题引发的 goroutine 相关源码的探究

本文主要是介绍由一个问题引发的 goroutine 相关源码的探究，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

　　本文基于 Go 语言 1.13.x 版本进行分析

　　在 Go 语言中文网微信群有人问了这么一个问题，如下代码：

　　const N = 26

　　func main() {

　　const GOMAXPROCS = 1

　　runtime.GOMAXPROCS(GOMAXPROCS)

　　var wg sync.WaitGroup

　　wg.Add(2 * N)

　　for i := 0; i < N; i++ {

　　go func(i int) {

　　defer wg.Done()

　　fmt.Printf("%c", 'a'+i)

　　}(i)

　　go func(i int) {

　　defer wg.Done()

　　fmt.Printf("%c", 'A'+i)

　　}(i)

　　}

　　wg.Wait()

　　}

　　问题：

　　为什么输出是 ZaAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYz，而不是 aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ如果想要输出 aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ，怎么做？

　　一看，这是个涉及到 goroutine 调度的问题。这里郑重警示：实际中，不要依赖任何调度器的调度顺序！当然，作为学习，我们可以来研究一下该问题。

　　根据现象，我们可以容易的想到如下很“奇葩”的解决方案，即在 wg.Wait() 之前开一个空 goroutine：

　　go func(){}()

　　除了这种方案，还有一种方案，那就是在 wg.Wait() 之前 Sleep，时间长短无所谓：

　　time.Sleep(1e9)

　　该问题和解决方案都着实让人困惑。下面就让我们一步步来揭示其中的原因。

　　我们通过一个简单的示例来猜测创建 goroutine 的顺序和执行 goroutine 的顺序的关系。也就是说，维护的是一个栈还是队列，亦或是其他的？

　　func main() {

　　// 为了验证问题，该句是必须的

　　runtime.GOMAXPROCS(1)

　　var wg sync.WaitGroup

　　wg.Add(2)

　　// goroutine 1

　　go func() {

　　defer wg.Done()

　　fmt.Println("first goroutine")

　　}()

　　// goroutine 2

　　go func() {

　　defer wg.Done()

　　fmt.Println("second goroutine")

　　}()

　　wg.Wait()

　　}

　　执行以上代码，输出：

　　second goroutine

　　first goroutine

　　如果调整两个 goroutine 的顺序，再执行，发现输出是：

　　first goroutine

　　second goroutine

　　由此似乎可以得出结论：goroutine 队列是后进先出。

　　我们尝试再加一个 goroutine。

　　func main() {

　　// 为了验证问题，该句是必须的

　　runtime.GOMAXPROCS(1)

　　var wg sync.WaitGroup

　　wg.Add(3)

　　// goroutine 1

　　go func() {

　　defer wg.Done()

　　fmt.Println("first goroutine")

　　}()

　　// goroutine 2

　　go func() {

　　defer wg.Done()

　　fmt.Println("second goroutine")

　　}()

　　// goroutine 3

　　go func() {

　　defer wg.Done()

　　fmt.Println("third goroutine")

　　}()

　　wg.Wait()

　　}

　　输出：

　　third goroutine

　　first goroutine

　　second goroutine

　　这又表明，并非是后进先出，顶多是：最后进的先出；其他的按先进先出的顺序。这也是本文开始问题的第 1 种解决方案。

　　回到 2 个 goroutine 的情况，我们改为如下方式：

　　func main() {

　　// 为了验证问题，该句是必须的

　　runtime.GOMAXPROCS(1)

　　// goroutine 1

　　go func() {

　　fmt.Println("first goroutine")

　　}()

　　// goroutine 2

　　go func() {

　　fmt.Println("second goroutine")

　　}()

　　time.Sleep(1)

　　}

　　输出：

　　first goroutine

　　second goroutine

　　什么鬼？怎么最后进的也不是先出了？

　　这也是为什么加上 time.Sleep() 本文开始的问题就解决了。

　　到此，似乎类似的问题知道怎么解决了，但为什么是这样的？

　　因为涉及到 goroutine 的调度，这里不得不搬出 Go 相关源码，但我会尽可能不让大家烧脑，用简单易懂的方式阐述。

　　你应该听过 Go 语言的 GMP 模型，这个必须有所了解（更多信息可以查阅本文最后提供的深入学习资料）。这里你只需要知道，P 中会有一个可运行（runnable）的 goroutine 队列。在 P 的结构体中，由 runq 字段保存，也就是 P 的本地可运行的 goroutine 队列。

　　type p struct {

　　...

　　runq [256]guintptr

　　...

　　}

　　创建一个 goroutine，对应是 runtime 包中的 newproc 函数，忽略一些细节，我们找到了 runqput 函数的调用：

　　runqput(_p_, newg, true)

　　该函数的签名如下：

　　// runqput tries to put g on the local runnable queue.

　　// If next is false, runqput adds g to the tail of the runnable queue.

　　// If next is true, runqput puts g in the _p_.runnext slot.

　　// If the run queue is full, runnext puts g on the global queue.

　　// Executed only by the owner P.

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

　　runqput 尝试把 G 放到本地执行队列中。这里的 next 很关键，next 参数如果是 false 的话，runqput 会将 G 放到运行队列的尾部。从上面代码看出，调用 runqput 时，next 传递的是 true，这时候会怎么处理呢？

　　我们要回到 P 结构体，其中有一个字段（runq 下一个字段）：

　　// runnext, if non-nil, is a runnable G that was ready'd by

　　// the current G and should be run next instead of what's in

　　// runq if there's time remaining in the running G's time

　　// slice. It will inherit the time left in the current time

　　// slice. If a set of goroutines is locked in a

　　// communicate-and-wait pattern, this schedules that set as a

　　// unit and eliminates the (potentially large) scheduling

　　// latency that otherwise arises from adding the ready'd

　　// goroutines to the end of the run queue.

　　runnext guintptr

　　runnext 非空时，代表的是一个 runnable 状态的 G，这个 G 是被 当前 G 修改为 ready 状态的，并且相比在 runq 中的 G 有更高的优先级。如果当前 G 还有剩余的可用时间，那么就应该运行这个 G。运行之后，该 G 会继承当前 G 的剩余时间。

　　这段话很重要。什么是当前 G ？比如在 main 函数中，我们创建一个 goroutine，那么 main 函数所在 goroutine（也就是 main goroutine）就是当前 G，而创建的 G 就是这句话所说的 runnable 状态的 G。

　　接着说 runqput 函数，当 next 为 true 时，当前 G 最后创建的 G 放在 runnext 中，但上一次创建的放在 runnext 中的怎么办呢？答案是移到 P 本地 G 队列的队尾。

　　到这里，你的疑惑应该差不多解开了。我们梳理下开始的问题：

　　因为 main goroutine 还有剩余可用时间，最后创建的 goroutine 优先执行，也就是打印Z 的先执行，其他部分按预期输出对于通过额外创建一个 goroutine 的方式来输出正常的结果，这里不需要额外解释了；

　　跟踪 time.Sleep 的源码，我们发现了 addtimerLocked 这个方法，留意其中如下代码：

　　if tb.rescheduling {

　　tb.rescheduling = false

　　goready(tb.gp, 0)

　　}

　　// 如果没有启动 timer 管理定时器，则启动。timerproc 只会启动一次，即全局 timer 管理器

　　if !tb.created {

　　tb.created = true

　　go timerproc(tb)

　　}

　　如果代码中第 1 次使用 time.Sleep，则会执行 go timerproc(tb)，这相当于又创建了一个 goroutine，它成为了 runnext。所以，main goroutine 之后，应该是先执行这个 goroutine，它负责管理全局 timer 定时器。（timerproc 函数不会返回）

　　更进一步，既然 timerproc 只会启动一次，那么我们在 main.main 一开始就 time.Sleep 一次，这样就不会因为 timerproc 这里的 G 占用 runnext 了。

　　实际上，这时进入了 addtimerLocked 方法中的 goready，它会把上面管理全局 timer 定时器的 G 放入 runnext。

　　可见，只要有 time.Sleep 后，runnext 中的 G 都是 timerproc 对应的 G，让它有尽可能多的机会检查 timer，而 timerproc 中有各种机制导致调度器重新调度，因此，runq 中的 G 得以调度执行。

　　我们永远不应该依赖调度器的调度顺序。然而，我们应该对调度器有所了解，知道它大致的调度策略，遇到问题，查阅资料、阅读源码，这个过程会对自己有很大的提升。

　　我希望你看此文时，能尝试着看看相关源码。不懂的地方肯定很多，我们只需抓住关心的点。欢迎一起交流学习！

　　Go语言源码 docs.studygolang/src/runtime/proc.go详尽干货！从源码角度看 Golang 的调度 studygolang/articles/20651雨痕《Go语言学习笔记》调度器相关源码剖析Xargin 调度器源码阅读 github/cch123/golang-notes/blob/master/scheduler.md调度器源码中文注释 github/zboya/golang_runtime_reading/blob/master/src/runtime/proc.go调度器剖析三部曲 studygolang/articles/14264 studygolang/articles/15316 studygolang/articles/17014Go work-stealing 调度器 studygolang/articles/12328Goroutine调度实例简要分析 studygolang/articles/11720也谈goroutine调度器 studygolang/articles/10116

　　欢迎补充其他资源！

这篇关于由一个问题引发的 goroutine 相关源码的探究的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！