在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 再次调度过来执行时，会继续原来的执行流。
基于信号的抢占式调度，抢占也只会在垃圾回收扫描任务时触发
