Golang抢占式调度

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

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

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


基于协作的抢占式调度

stackguard0StackPreemptruntime.newstack:1e112cdstackguard0StackPreempt

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

stackguard0runtime.morestackstackguard0StackPreemptruntime.morestackruntime.newstack

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

runtime.morestackruntime.newstackStackPreemptruntime.morestackruntime.newstackstackguard0StackPreemptstackguard0StackPreempt

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

image-20210913215417567

这段代码在这种调度方式下会阻塞，是因为空的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 再次调度过来执行时，会继续原来的执行流。


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