深度解密Go语言之基于信号的抢占式调度

作者 | qcrao       责编 | 欧阳姝黎

不知道大家在实际工作中有没有遇到过老版本 Go 调度器的坑&＃xff1a;死循环导致程序“死机”。我去年就遇到过&＃xff0c;并且搞出了一起 P0 事故&＃xff0c;还写了篇弱智的找 bug 文章。

识别事故的本质&＃xff0c;并且用一个非常简单的示例展示出来&＃xff0c;是功力的一种体现。那次事故的原因可以简化成如下的 demo&＃xff1a;

demo-1

我来简单解释一下上面这个程序。在主 goroutine 里&＃xff0c;先用 GoMAXPROCS 函数拿到 CPU 的逻辑核心数 threads。这意味着 Go 进程会创建 threads 个数的 P。接着&＃xff0c;启动了 threads 个数的 goroutine&＃xff0c;每个 goroutine 都在执行一个无限循环&＃xff0c;并且这个无限循环只是简单地执行 x&＃43;&＃43;。

接着&＃xff0c;主 goroutine sleep 了 1 秒钟&＃xff1b;最后&＃xff0c;打印 x 的值。

你可以自己思考一下&＃xff0c;输出会是什么&＃xff1f;

如果你想出了答案&＃xff0c;接着再看下面这个 demo&＃xff1a;

demo-2

我也来解释一下&＃xff0c;在主 goroutine 里&＃xff0c;只启动了一个 goroutine&＃xff08;虽然程序里用了一个 for 循环&＃xff0c;但其实只循环了一次&＃xff0c;完全是为了和前面的 demo 看起来更协调一些&＃xff09;&＃xff0c;同样执行了一个 x&＃43;&＃43; 的无限 for 循环。

和前一个 demo 的不同点在于&＃xff0c;在主 goroutine 里&＃xff0c;我们手动执行了一次 GC&＃xff1b;最后&＃xff0c;打印 x 的值。

如果你能答对第一题&＃xff0c;大概率也能答对第二题。

下面我就来揭晓答案。

其实我留了一个坑&＃xff0c;我没说用哪个版本的 Go 来运行代码。所以&＃xff0c;正确的答案是&＃xff1a;

这个其实就是 Go 调度器的坑了。

假设在 demo-1 中&＃xff0c;共有 4 个 P&＃xff0c;于是创建了 4 个 goroutine。当主 goroutine 执行 sleep 的时候&＃xff0c;刚刚创建的 4 个 goroutine 马上就把 4 个 P 霸占了&＃xff0c;执行死循环&＃xff0c;而且竟然没有进行函数调用&＃xff0c;就只有一个简单的赋值语句。Go 1.13 对这种情况是无能为力的&＃xff0c;没有任何办法让这些 goroutine 停下来&＃xff0c;进程对外表现出“死机”。

demo-1 示意图

由于 Go 1.14 实现了基于信号的抢占式调度&＃xff0c;这些执行无限循环的 goroutine 会被调度器“拿下”&＃xff0c;P 就会空出来。所以当主 goroutine sleep 时间到了之后&＃xff0c;马上就能获得 P&＃xff0c;并得以打印出 x 的值。至于 x 为什么输出的是 0&＃xff0c;不太好解释&＃xff0c;因为这是一种未定义&＃xff08;有数据竞争&＃xff0c;正常情况下要加锁&＃xff09;的行为&＃xff0c;可能的一个原因是 CPU 的 cache 没有来得及更新&＃xff0c;不过不太好验证。

理解了这个 demo&＃xff0c;第二个 demo 其实是类似的道理&＃xff1a;

demo-2 示意图

当主 goroutine 主动触发 GC 时&＃xff0c;需要把所有当前正在运行的 goroutine 停止下来&＃xff0c;即 stw&＃xff08;stop the world&＃xff09;&＃xff0c;但是 goroutine 正在执行无限循环&＃xff0c;没法让它停下来。当然&＃xff0c;Go 1.14 还是可以抢占掉这个 goroutine&＃xff0c;从而打印出 x 的值&＃xff0c;也是 0。

Go 1.14 之前的版本&＃xff0c;能否抢占一个正在执行死循环的 goroutine 其实是有讲究的&＃xff1a;

能否被抢占&＃xff0c;不是看有没有调用函数&＃xff0c;而是看函数的序言部分有没有插入扩栈检测指令。

如果没有调用函数&＃xff0c;肯定不会被抢占。

有些虽然也调用了函数&＃xff0c;但其实不会插入检测指令&＃xff0c;这个时候也不会被抢占。

像前面的两个 demo&＃xff0c;不可能有机会在函数扩栈检测期间主动放弃 CPU 使用权&＃xff0c;从而完成抢占&＃xff0c;因为没有函数调用。具体的过程后面有机会再写一篇文章详细讲&＃xff0c;本文主要看基于信号的抢占式调度如何实现。

preemptone

一方面&＃xff0c;Go 进程在启动的时候&＃xff0c;会开启一个后台线程 sysmon&＃xff0c;监控执行时间过长的 goroutine&＃xff0c;进而发出抢占。另一方面&＃xff0c;GC 执行 stw 时&＃xff0c;会让所有的 goroutine 都停止&＃xff0c;其实就是抢占。这两者都会调用 preemptone() 函数。

preemptone() 函数会沿着下面这条路径&＃xff1a;

preemptone->preemptM->signalM->tgkill


向正在运行的 goroutine 所绑定的的那个 M&＃xff08;也可以说是线程&＃xff09;发出 SIGURG 信号。

注册 sighandler

每个 M 在初始化的时候都会设置信号处理函数&＃xff1a;

initsig->setsig->sighandler


信号执行过程

我们从“宏观”层面看一下信号的执行过程&＃xff1a;

信号执行过程

主程序&＃xff08;线程&＃xff09;正在“勤勤恳恳”地执行指令&＃xff1a;它已经执行完了指令 m&＃xff0c;接着就要执行指令 m&＃43;1 了……不幸在这个时候发生了&＃xff0c;线程收到了一个信号&＃xff0c;对应图中的 ①。

接着&＃xff0c;内核会接管执行流&＃xff0c;转而去执行预先设置好的信号处理器程序&＃xff0c;对应到 Go 里&＃xff0c;就是执行 sighandler&＃xff0c;对应图中的 ② 和 ③。

最后&＃xff0c;执行流又交到线程手上&＃xff0c;继续执行指令 m&＃43;1&＃xff0c;对应图中的 ④。

这里其实涉及到了一些现场的保护和恢复&＃xff0c;内核都帮我们搞定了&＃xff0c;我们不用操心。

dosigPreempt

当线程收到 SIGURG 信号的时候&＃xff0c;就会去执行 sighandler 函数&＃xff0c;核心是 doSigPreempt 函数。

func sighandler(sig uint32, info *siginfo, ctxt unsafe.Pointer, gp *g) {...if sig &＃61;&＃61; sigPreempt && debug.asyncpreemptoff &＃61;&＃61; 0 {doSigPreempt(gp, c)}...
}

doSigPreempt 这个函数其实很短&＃xff0c;一会儿就执行完了。

func doSigPreempt(gp *g, ctxt *sigctxt) {...if ok, newpc :&＃61; isAsyncSafePoint(gp, ctxt.sigpc(), ctxt.sigsp(), ctxt.siglr()); ok {// Adjust the PC and inject a call to asyncPreempt.ctxt.pushCall(funcPC(asyncPreempt), newpc)}...
}


isAsyncSafePoint 函数会返回当前 goroutine 能否被抢占&＃xff0c;以及从哪条指令开始抢占&＃xff0c;返回的 newpc 表示安全的抢占地址。

接着&＃xff0c;pushCall 调整了一下 SP&＃xff0c;设置了几个寄存器的值就返回了。按理说&＃xff0c;返回之后&＃xff0c;就会接着执行指令 m&＃43;1 了&＃xff0c;但那还怎么实现抢占呢&＃xff1f;其实魔法都在 pushCall 这个函数里。

pushCall

在分析这个函数之前&＃xff0c;我们需要先复习一下 Go 函数的调用规约&＃xff0c;重点回顾一下 CALL 和 RET 指令就行了。

call 指令可以简单地理解为 push ip &＃43; JMP。这个 ip 其实就是返回地址&＃xff0c;也就是调用完子函数接下来该执行啥指令的地址。所以 push ip 就是在 call 一个子函数之前&＃xff0c;将返回地址压入栈中&＃xff0c;然后 JMP 到子函数的地址执行。

ret 指令和 call 指令刚好相反&＃xff0c;它将返回地址从栈上 pop 到 IP 寄存器&＃xff0c;使得 CPU 从这个地址继续执行。

理解了 call 和 ret&＃xff0c;我们再来分析 pushCall 函数&＃xff1a;

func (c *sigctxt) pushCall(targetPC, resumePC uintptr) {// Make it look like we called target at resumePC.sp :&＃61; uintptr(c.rsp())sp -&＃61; sys.PtrSize*(*uintptr)(unsafe.Pointer(sp)) &＃61; resumePCc.set_rsp(uint64(sp))c.set_rip(uint64(targetPC))
}


注意看这行注释&＃xff1a;

// Make it look like we called target at resumePC.


它清晰地说明了这个函数的作用&＃xff1a;让 CPU 误以为是 resumePC 调用了 targetPC。而这个 resumePC 就是上一步调用 isAsyncSafePoint 函数返回的 newpc&＃xff0c;它代表我们抢占 goroutine 的指令地址。

前两行代码将 SP 下移了 8 个字节&＃xff0c;并且把 resumePC 入栈&＃xff08;注意&＃xff0c;它其实是一个返回地址&＃xff09;&＃xff0c;接着把 targetPC 设置到 ip 寄存器&＃xff0c;sp 设置到 SP 寄存器。这使得从内核返回到用户态执行时&＃xff0c;不是从指令 m&＃43;1&＃xff0c;而是直接从 targetPC 开始执行&＃xff0c;等到 targetPC 执行完&＃xff0c;才会返回到 resumePC 继续执行。整个过程就像是 resumePC 调用了 targetPC 一样。而 targetPC 其实就是 funcPC(asyncPreempt)&＃xff0c;也就是抢占函数。

于是我们可以看到&＃xff0c;信号处理器程序 sighandler 只是将一个异步抢占函数给“安插”进来了&＃xff0c;而真正的抢占过程则是在 asyncPreempt 函数中完成。

异步抢占

当执行完 sighandler&＃xff0c;执行流再次回到线程。由于 sighandler 插入了一个 asyncPreempt 的函数调用&＃xff0c;所以 goroutine 原本的任务就得不到推进&＃xff0c;转而执行 asyncPreempt 去了&＃xff1a;

asyncPreempt 调用链路

mcall(fn) 的作用是切到 g0 栈去执行函数 fn, fn 永不返回。在 mcall(gopreempt_m) 这里&＃xff0c;fn 就是 gopreempt_m。

gopreempt_m 直接调用 goschedImpl&＃xff1a;

最精彩的部分就在 goschedImpl 函数。它首先将 goroutine 的状态从 running 改成 runnable&＃xff1b;接着调 dropg 将 g 和 m 解绑&＃xff1b;然后调用 globrunqput 将 goroutine 丢到全局可运行队列&＃xff0c;由于是全局可运行队列&＃xff0c;所以需要加锁。最后&＃xff0c;调用 schedule() 函数进入调度循环。关于调度循环&＃xff0c;可以看这篇文章。

运行 schedule 函数用的是 g0 栈&＃xff0c;它会去寻找其他可运行的 goroutine&＃xff0c;包括从当前 P 本地可运行队列获取、从全局可运行队列获取、从其他 P 偷等方式找到下一个可运行的 goroutine 并执行。

至此&＃xff0c;这个线程就转而去执行其他的 goroutine&＃xff0c;当前的 goroutine 也就被抢占了。

那被抢占的这个 goroutine 什么时候会再次得到执行呢&＃xff1f;

因为它已经被丢到全局可运行队列了&＃xff0c;所以它的优先级就会降低&＃xff0c;得到调度的机会也就降低&＃xff0c;但总还是有机会再次执行的&＃xff0c;并且它会从调用 mcall 的下一条指令接着执行。

还记得 mcall 函数的作用吗&＃xff1f;它会切到 g0 栈执行 gopreempt_m&＃xff0c;自然它也会保存 goroutine 的执行进度&＃xff0c;其实就是 SP、BP、PC 寄存器的值&＃xff0c;当 goroutine 再次被调度执行时&＃xff0c;就会从原来的执行流断点处继续执行下去。

总结

本文讲述了 Go 语言基于信号的异步抢占的全过程&＃xff0c;一起来回顾下&＃xff1a;

1. M 注册一个 SIGURG 信号的处理函数&＃xff1a;sighandler。

2. sysmon 线程检测到执行时间过长的 goroutine、GC stw 时&＃xff0c;会向相应的 M&＃xff08;或者说线程&＃xff0c;每个线程对应一个 M&＃xff09;发送 SIGURG 信号。

3. 收到信号后&＃xff0c;内核执行 sighandler 函数&＃xff0c;通过 pushCall 插入 asyncPreempt 函数调用。

4. 回到当前 goroutine 执行 asyncPreempt 函数&＃xff0c;通过 mcall 切到 g0 栈执行 gopreempt_m。

5. 将当前 goroutine 插入到全局可运行队列&＃xff0c;M 则继续寻找其他 goroutine 来运行。

6. 被抢占的 goroutine 再次调度过来执行时&＃xff0c;会继续原来的执行流。

期待你的关注~

☞华为今年不发布Mate系列新机&＃xff1b;一加宣布与OPPO合并&＃xff1a;将成为OPPO旗下独立品牌&＃xff1b;Gradle 7.1 发布|极客头条☞Windows 11 预览版泄露&＃xff01;有 macOS 那味儿了......
☞Web 3.0 宣言&＃xff1a;为什么 Web 3.0 至关重要