Go Runtime的调度器

以goroutine形式进行Go并发编程是一种很是方便的方法，但有没有想过他是如何有效地运行这些goroutine？下面从设计的角度，深刻了解和研究Go运行时调度程序，以及如何在性能调试过程当中使用它来解释Go程序的调度程序跟踪信息。

要了解为何须要有一个运行时的调度以及它是如何工做的，先要回到操做系统的历史上，在这里将找到答案，由于若是不了解问题的根源。

操做系统的历史

1. 单用户（无操做系统）
2. 批处理 单编程 运行完成
3. 多程序

多程序的目的是使CPU和I/O重叠。如何作到的呢？

• 多批次
  IBM OS / MFT（具备固定数量的任务的多重编程）
• 多批次
  IBM OS / MVT（具备可变数量的任务的多重编程）—在这里，每一个做业仅得到其所需的内存量。即，随着做业的进出，内存的分区发生变化。
• 分时
  这是在做业之间快速切换的多道程序设计。决定什么时候切换以及切换到哪些做业称为调度。

现代大多数操做系统使用分时调度程序。

这些调度程序调度的是什么呢？
1 不一样的程序正在执行（进程）
2 做为进程子集存在的CPU利用率（线程）的基本单位

这些都是有代价的。

调度成本

所以，使用一个包含多个线程的进程效率更高，由于进程建立既耗时又耗费资源。随后出现了多线程问题：C10k问题是主要的问题。

例如，若是将调度程序周期定义为10毫秒（毫秒），而且有2个线程，则每一个线程将分别得到5毫秒。若是您有5个线程，则每一个线程将得到2ms。可是，若是有1000个线程怎么办？给每一个线程10s（微秒）的时间片？你将花费大量时间进行上下文切换，可是没法完成真正的工做。

你须要限制时间片的长度。在最后一种状况下，若是最小时间片是2ms，而且有1000个线程，则调度程序周期须要增长到2s（秒）。若是有10,000个线程，则调度程序周期为20秒。在这个简单的示例中，若是每一个线程都使用其全时切片，则全部线程一次运行须要20秒。所以，咱们须要一些可使并发成本下降而又不会形成过多开销的东西。

用户级线程
• 线程彻底由运行时系统（用户级库）管理。
• 理想状况下，快速高效：切换线程不比函数调用贵多少。
• 内核对用户级线程一无所知，并像对待单线程进程同样对其进行管理。

在Go中，咱们叫它“ Goroutine”（在逻辑上）

Goroutine

协程是轻量级线程，由Go运行时管理（逻辑上一个执行的线程）。要go在函数调用以前启动运行go关键字。

func main() {
    var wg sync.WaitGroup
    wg.Add(11)
    for i := 0; i <= 10; i++ {
   
        go func(i int) {
          defer wg.Done()
          fmt.Printf("loop i is - %d\n", i)
        }(i)
    }
    wg.Wait()
    fmt.Println("Hello, Welcome to Go")
}
运行结果

loop i is - 10
loop i is - 0
loop i is - 1
loop i is - 2
loop i is - 3
loop i is - 4
loop i is - 5
loop i is - 6
loop i is - 7
loop i is - 8
loop i is - 9
Hello, Welcome to Go

看一下输出，就会有两个问题。

1. 11个goroutine如何并发运行的？
2. goroutine以什么顺序运行？

这两个问题，又引起新的思考：

1. 如何将这些多个 goroutine 分布到在可用 CPU 处理器上运行的多个 OS 线程上。
2. 这些多个 goroutine 应该以什么顺序运行以保持公平性？

其他的讨论将主要围绕从设计角度解决 Go 运行时调度程序的这些问题。调度程序可能会瞄准许多目标中的一个或多个，对于咱们的案例，咱们将限制本身知足如下要求。

1. 应该是并行的、可扩展的、公平的。
2. 每一个进程应可扩展到数百万个goroutine（10⁶）
3. 内存高效。（RAM很便宜，但不是免费的。）
4. 系统调用不该致使性能降低。（最大化吞吐量，最小化等待时间）

所以，让咱们开始为调度程序建模，以逐步解决这些问题。

1.每一个Goroutine线程——用户级线程。

  限制

    1.并行和可扩展。
      * 并行
      * 可扩展
    2. 每一个进程不能扩展到数百万个goroutine（10⁶）

2.M:N线程——混合线程

M个内核线程执行N个“ goroutine”

M个内核线程执行N个“ goroutine”

代码和并行的实际执行须要内核线程。可是建立成本很高，因此将 N 个 goroutine 映射到 M Kernel Thread。Goroutine 是 Go Code，因此咱们能够彻底控制它。此外，它在用户空间中，所以建立起来很便宜。

可是由于操做系统对 goroutine 一无所知。每一个 goroutine 都有一个 state 来帮助Scheduler根据 goroutine state 知道要运行哪一个 goroutine。与内核线程相比，这个状态信息很小，goroutine 的上下文切换变得很是快。

• Running-当前在内核线程上运行的goroutine。
• Runnable-够程等待内核线程来运行。
• Blocked-等待某些条件的Goroutine（例如，在通道，系统调用，互斥体等上被阻止）

2个线程一次运行2个

所以，Go Runtime Scheduler经过将N Goroutine复用到M内核线程来管理处于各类状态的这些goroutine。

简单的MN排程器
在咱们简单的M:N Scheduler中，咱们有一个全局运行队列，某些操做将一个新的goroutine放入运行队列。M个内核线程访问调度程序以从“运行队列”中获取goroutine来运行。多个线程尝试访问相同的内存区域，咱们将使用Mutex For Memory Access Synchronization锁定此结构。

简单的M:N

阻塞的goroutine在哪里？
能够阻塞的goroutine一些实例。

1. 在channel上发送和接收。
2. 网络I/O。
3. 阻止系统调用。
4. 计时器。
5. 互斥体。

那么，咱们将这些阻塞的goroutine放在哪里？

阻塞的goroutine不该阻塞底层的内核线程！（避免线程上下文切换成本）

通道操做期间阻止了Goroutine。
每一个通道都有一个recvq（waitq），用于存储被阻止的goroutine，这些goroutine试图从该通道读取数据。
Sendq（waitq）存储试图将数据发送到通道的被阻止的goroutine 。

通道操做期间阻止了Goroutine。

通道操做后的未阻塞的goroutine被通道放入“运行”队列。

通道操做后接触阻塞的goroutine

系统调用呢？

首先，让咱们看看阻塞系统调用。一个阻塞底层内核线程的系统调用，因此咱们不能在这个线程上调度任何其余 Goroutine。

隐含阻塞系统调用下降了并行级别。

不能在 M2 线程上调度任何其余 Goroutine，致使CPU 浪费。

咱们能够恢复并行度的方法是，当咱们进入系统调用时，咱们能够唤醒另外一个线程，该线程将从运行队列中选择可运行的 goroutine。

如今，当系统调用完成时，超额执行了Groutine计划。为了不这种状况，咱们不会当即运行Goroutine从阻止系统调用中返回。可是咱们会将其放入调度程序运行队列中。

避免过分预约的调度

所以，当咱们的程序运行时，线程数大于内核数。尽管没有明确说明，线程数大于内核数，而且全部空闲线程也都由运行时管理，以免过多的线程。

初始设置为10,000个线程，若是超过则程序崩溃。

非阻塞系统调用---在集成运行时轮询器上阻塞 goroutine ，并释放线程以运行另外一个 goroutine。

例如在非阻塞 I/O 的状况下，例如 HTTP 调用。第一个系统调用 - 遵循先前的工做流程 - 不会成功，由于资源还没有准备好，迫使 Go 使用网络轮询器并停放 goroutine。

这是部分 net.Read功能的实现。

n, err := syscall.Read(fd.Sysfd, p)
if err != nil {
  n = 0
  if err == syscall.EAGAIN && fd.pd.pollable() {
    if err = fd.pd.waitRead(fd.isFile); err == nil {
    continue
  }
}

一旦完成第一个系统调用并明确指出资源还没有准备好，goroutine将停放，直到网络轮询器通知它资源已准备好为止。在这种状况下，线程M将不会被阻塞。

Poller将基于操做系统使用select/kqueue/epoll/IOCP来了解哪一个文件描述符已准备好，一旦文件描述符准备好进行读取或写入，它将把goroutine放回到运行队列中。

还有一个Sysmon OS线程，若是轮询时间不超过10毫秒，它将按期轮询网络，并将就绪G添加到队列中。

基本上全部的goroutine都被阻止在

1. 渠道
2. 互斥体
3. 网络IO
4. 计时器

如今，运行时具备具备如下功能的调度程序。

• 它能够处理并行执行（多线程）。
• 处理阻止系统调用和网络I/O。
• 处理阻止用户级别（在通道上）的调用。

但这不是可扩展的

使用Mutex的全局运行队列

如图所见，咱们有一个Mutex全局运行队列，最终会遇到一些问题，例如

1. 缓存一致性保证的开销。
2. 在建立，销毁和调度Goroutine G时进行激烈的锁争用。

使用分布式调度器克服可扩展性的问题。

分布式调度程序—每一个线程运行队列。

分布式运行队列调度程序

这样，咱们能够看到的直接好处是，对于每一个线程本地运行队列，咱们如今都没有互斥体。仍然有一个带有互斥量的全局运行队列，在特殊状况下使用。它不会影响可伸缩性。

如今，咱们有多个运行队列。

1. 本地运行队列
2. 全局运行队列
3. 网络轮训器

咱们应该从哪里运行下一个goroutine？

在Go中，轮询顺序定义以下。

1. 本地运行队列
2. 全局运行队列
3. 网络轮训器
4. 工做偷窃（Work Stealing）

即首先检查本地运行队列，若是为空则检查全局运行队列，而后检查网络轮询器，最后进行窃取工做。到目前为止，咱们对1,2,3有了一些概述。让咱们看一下“窃取工做”。

工做偷窃

若是本地工做队列为空，请尝试“从其余队列中窃取工做”

“偷窃”工做

当一个线程有太多的工做要作而另外一个线程处于空闲状态时，工做窃取解决了这个问题。在Go中，若是本地队列为空，窃取工做将尝试知足如下条件之一。

• 从全局队列中拉取工做。
• 从网络轮询器中拉取工做。
• 从其余本地队列中窃取工做。

到目前为止，运行时Go具备具备如下功能的Scheduler。

• 它能够处理并行执行（多线程）。
• 处理阻止系统调用和网络I/O。
• 处理阻止用户级别（在通道上）的调用。
• 可扩展

但这不是有效的。

还记得咱们在阻塞系统调用中恢复并行度的方式吗？

它的含义是，在一个系统调用中咱们能够有多个内核线程（能够是10或1000），这可能会增长内核数。咱们最终在如下期间产生了恒定的开销：

• 窃取工做时，它必须同时扫描全部内核线程（理想状况下并使用goroutine运行）本地运行队列，而且大多数都将为空。
• 垃圾回收，内存分配器都遭受相同的扫描问题。

使用M:P:N线程克服效率问题。

3.M：P：N（3级调度程序）线程化—逻辑处理器P简介

P — 处理器，能够将其视为在线程上运行的本地调度程序；

M:P:N线程

逻辑进程P的数量始终是固定的。（默认为当前进程可使用的逻辑CPU）

将本地运行队列（LRQ）放入固定数量的逻辑处理器（P）中。

分布式三级运行队列调度程序

Go运行时将首先根据计算机的逻辑CPU数量（或根据请求）建立固定数量的逻辑处理器P。

每一个goroutine（G）将在分配给逻辑CPU（P）的OS线程（M）上运行。

所以，如今咱们在如下期间没有固定的开销：

• 窃取工做-只需扫描固定数量的逻辑处理器（P）本地运行队列。
• 垃圾回收，内存分配器也得到相同的好处。

带有固定逻辑处理器（P）的系统调用怎么样？

Go经过将系统调用包装在运行时中来优化系统调用-不管它是否阻塞

阻止系统调用包装器

Blocking SYSCALL方法封装在runtime.entersyscall（SB）
runtime.exitsyscall（SB）之间。
从字面上看，某些逻辑在进入系统调用以前执行，而某些逻辑在退出系统调用以后执行。进行阻塞系统调用时，此包装器将自动从线程M分离P，并容许另外一个线程在其上运行。

阻塞系统调用切换P

这容许 Go 运行时在不增长运行队列的状况下有效地处理阻塞系统调用。

一旦阻止syscall退出，会发生什么？

• 运行时尝试获取彻底相同的P，而后继续执行。
• 运行时尝试在空闲列表中获取一个P并恢复执行。
• 运行时将goroutine放到全局队列中，并将关联的M放回空闲列表。

自旋线程和理想线程（Spinning Thread and Ideal Thread）.

当M2线程在syscall返回后变成理想理想线程时。该理想的M2线程该怎么办。理论上，一个线程若是完成了它须要作的事情就应该被操做系统销毁，而后其余进程中的线程可能会被 CPU 调度执行。这就是咱们常说的操做系统中线程的“抢占式调度”。

考虑上述syscall中的状况。若是咱们销毁了M2线程，而M3线程即将进入syscall。此时，在建立新的内核线程并将其计划由OS执行以前，没法处理可运行的goroutine。频繁的线程前抢占操做不只会增长OS的负载，并且对于性能要求更高的程序几乎是不可接受的。

所以，为了正确利用操做系统的资源并防止频繁的线程抢占操做系统上的负载，咱们不会破坏内核线程M2，而是进行自旋操做并保存以备未来使用。尽管这彷佛是在浪费一些资源。可是，与线程之间的频繁抢占以及频繁的建立和销毁操做相比，“理想的线程”仍然要付出更少的代价。

Spinning Thread —例如，在具备一个内核线程M（1）和一个逻辑处理器（P）的Go程序中，若是正在执行的M被syscall阻止，则“ Spinning Threads”的数目与该数目相同须要P的值以容许等待的可运行goroutine继续执行。所以，在此期间，内核线程的数量M大于P的数量（旋转线程+阻塞线程）。所以，即便将runtime.GOMAXPROCSvalue设置为1，程序也将处于多线程状态。

调度中的公平性如何？—公平选择下一步要执行的goroutine。

与许多其余调度程序同样，Go也具备公平性约束，而且由goroutine的实现所强加，由于Runnable goroutine应该最终运行

如下是Go Runtime Scheduler中的四个典型的公平性约束。

任何运行超过 10 毫秒的 goroutine 都被标记为可抢占（软限制）。可是，抢占仅在函数序言中完成。Go 目前在函数 prologues 中使用编译器插入的合做抢占点。

    无限循环——抢占（~10ms 时间片）——软限制

可是要当心无限循环，由于 Go 的调度程序不是抢占式的（直到 1.13）。若是循环不包含任何抢占点（如函数调用或分配内存），它们将阻止其余 goroutine 运行。一个简单的例子是：

package main
func main() {
    go println("goroutine ran")
    for {}
}

执行命令

GOMAXPROCS = 1 go run main.go

直到Go（1.13）才可能打印该语句。因为缺乏抢占点，所以主要的Goroutine能够占用处理器。

• 本地运行队列-抢占（〜10ms时间片）-软限制
• 经过每61个调度程序刻度检查一次全局运行队列，能够避免全局运行队列饥饿。
• Network Poller Starvation后台线程轮询网络偶尔会被主工做线程轮询。

Go 1.14有一个新的“非合做式抢占”。

有了Go，Runtime有了一个Scheduler，它具备全部必需的功能。

• 它能够处理并行执行（多线程）。
• 处理阻止系统调用和网络I / O。
• 处理阻止用户级别（在通道上）的调用。
• 可扩展
• 高效的。
• 公平的。

这提供了大量的并发性，而且始终尝试实现最大的利用率和最小的延迟。

如今，咱们整体上对Go运行时调度程序有了一些了解，咱们如何使用它？Go为咱们提供了一个跟踪工具，即调度程序跟踪，目的是提供有关行为的看法并调试与goroutine调度程序有关的可伸缩性问题。

调度程序跟踪

使用GODEBUG = schedtrace = DURATION环境变量运行Go程序以启用调度程序跟踪。（DURATION是以毫秒为单位的输出周期。）