标签：goroutine 抢占 Goroutine 式调度 Golang 详解 线程 runtime
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 再次调度过来执行时，会继续原来的执行流。
标签：goroutine,抢占,Goroutine,式调度,Golang,详解,线程,runtime 来源： https://www.cnblogs.com/CJ-cooper/p/15265189.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。