go运行时机制(1) - 调度模型

golang以其强大的并发能力在io密集型应用场景下得到了广泛的应用，goroutine & channel & runtime机制的引入能够使得开发者能以较低的心智负担和较高的开发效率开发高性能的应用。

goroutine在创建之后，由runtime在用户态进行调度，即用协程取代了线程。

关于线程与协程的区别，参见博文：

https://blog.csdn.net/kakaweb/article/details/102492856

linux系统提供了ucontext系列api，我们可以基于这些api手动地yield和resume，从而实现线程的用户态调度。相比之下，golang中，只要通过关键字go就可以创建一个协程，将协程的调度托管给runtime进行。

那么，runtime是如何处理goroutine调度的？为什么golang开发的应用程序能够轻易创建上万个goroutine并平稳运行？

在goroutine调度模型中，有几个重要的概念需要明确：

• P(logical processor)
  • 一个抽象的上下文，可以用GOMAXPROCS设置
• M(os thread)
  • 工作线程，是真实用于执行goroutine的单元
  • M为了执行goroutine必须和P绑定从而获取可执行的goroutine
  • M按需创建
• G(goroutine)
  • goroutine
• LRQ
  • 绑定在P上的代执行goroutine队列
• GRQ
  • 全局goroutine队列

相互间的关系如图所示

和常见的coroutine实现中1:N调度模型不同，goroutine所采用的是M:N的调度模型，即M个用户态的工作线程负责N个goroutine的运行。

goroutine的状态

goroutine状态与线程状态类似，可以分为如下三种：

• waiting: goroutine已经停止并且等待系统调用/mutex操作完成
• executing: 不解释
• runnable: goroutine正在等待M上的时间片，可认为处于LRQ/GRQ中

运行时scheduler

与linux内核类似，go sheduler采用的是抢占式调度模型，在如下四个时机可能触发调度：

• 使用关键字go开启新协程
• gc
  • gc占用部分M的时间片，触发调度
• 系统调用
  • 系统调用阻塞M，调度器将新的goroutine置于该M运行或创建新的M
• 同步和锁操作
  • mutex/channel操作将导致goroutine block，触发context-switch

work stealing

当某个P上没有可执行的goroutine时，调度器将协助从其它P的LRQ或GRQ中获取runnable状态的goroutine转移至当前goroutine运行，以提高效率。

 

参考文章：

https://www.ardanlabs.com/blog/2018/08/scheduling-in-go-part2.html