【Golang详解】go语言调度机制 抢占式调度

Golang抢占式调度

在1.2版本之前，go的调度器仍然不支持抢占式调度，程序只能依靠Goroutine主动让出CPU资源才能触发调度，这会引发一些问题，比如：

• 某些 Goroutine 可以长时间占用线程，造成其它 Goroutine 的饥饿
• 垃圾回收器是需要stop the world的。如果垃圾回收器想要运行了，那么它必须先通知其它的goroutine合作停下来，这会造成较长时间的等待时间。

之后go team意识到这个问题，首先推出了基于协作的抢占式调度

基于协作的抢占式调度

Go团队为 Goroutine 引入 stackguard0 字段，当该字段被设置成 StackPreempt 意味着当前 Goroutine 发出了抢占请求；同时在 runtime.newstack:1e112cd 中增加抢占的代码，当 stackguard0 等于 StackPreempt 时触发调度器抢占让出线程；

1.13版本 go依赖调用函数栈增长检测代码的方式

gorogoutine创建之初，栈的大小是固定的，为了防止栈溢出，编译器会在有明显栈消耗的函数头部插入一些检测代码，通过stackguard0值来决定是否触发runtime.morestack函数。将stackguard0设置为StackPreempt 作用是进入函数时必定触发runtime.morestack，然后在调用runtime.newstack。

所以基于协作的抢占式调度的工作机制就是：

• 编译器会在调用函数前插入 runtime.morestack，可能会调用runtime.newstack进行抢占
• Go 语言运行时会在垃圾回收暂停程序、系统监控发现 Goroutine 运行超过 10ms 时发出抢占请求 StackPreempt
• 当发生函数调用时，可能会执行编译器插入的 runtime.morestack，它调用的 runtime.newstack会检查 Goroutine 的 stackguard0 字段是否为 StackPreempt；
• 如果 stackguard0 是 StackPreempt，就会触发抢占让出当前线程；

但是这种调度并不完备，比如一个goroutine运行了很久，但是它并没有调用另一个函数，则它不会被抢占。例如

这段代码在这种调度方式下会阻塞，是因为空的for循环没有调用函数

在Go的1.14版本中实现了非协作的抢占式调度

基于信号的抢占式调度

在之前的依赖栈增长检测代码的方式，遇到没有函数调用的情况下就会出现问题，在Go1.14这一问题得到解决。

在Linux中这种真正的抢占式调度是基于信号完成的，所以也称为“异步抢占”

“异步抢占”工作机制：

• M 注册一个 SIGURG 信号的处理函数：sighandler。

• sysmon 线程检测到执行时间过长的 goroutine 或者GC stw 时，会向相应的 M（或者说线程，每个线程对应一个 M）发送 SIGURG 信号。

• 收到信号后，内核执行 sighandler 函数，通过 pushCall 插入 asyncPreempt 函数调用。

• 回到当前 goroutine 执行 asyncPreempt 函数，通过 mcall 切到 g0 栈执行 gopreempt_m。

• 将当前 goroutine 插入到全局可运行队列，M 则继续寻找其他 goroutine 来运行。

• 被抢占的 goroutine 再次调度过来执行时，会继续原来的执行流。

基于信号的抢占式调度，抢占也只会在垃圾回收扫描任务时触发