理解golang调度之二 ：Go调度器

前言

这一部分有三篇文章，主要是讲解go调度器的一些内容

三篇文章分别是:

• 理解golang调度之一 ：操做系统调度
• 理解golang调度之二 ：Go调度器
• 理解golang调度之三：并发

简介

第一篇文章解释了关于操做系统层级的调度，我认为这对于理解Go的调度是很重要的。这一部分我会在语义层级解释Go调度器是如何工做的，而且着重关注它的一些高级行为。Go 调度器是一个十分复杂的系统，细节不重要，重要的是对于其工做和行为有一个好的理解,这会让你作出更好的工程方面的决定。

从一个程序开始

当你的go程序启动，主机上定义的每个虚拟内核都会为它分配一个逻辑处理器(P)，若是你的处理器上每一个物理内核有多个硬件线程（超线程），每一个硬件线程对于你的go程序来讲就是一个虚拟内核。为了理解这个事情，看一下个人MacBook Pro的系统配置。

图2.1

你能够看到一个单独处理器有4个物理核心。配置表没有显示每一个物理核心有多少个硬件线程。Intel Core i7 处理器有本身的超线程，也就是每一个物理内核上有两个硬件线程。所以Go程序知道并行执行操做系统线程的时候，会有8个虚拟内核能够用

为了测试这个事情，看一下下面的程序

L1

package main

import (
	"fmt"
	"runtime"
)

func main() {

    // NumCPU returns the number of logical
    // CPUs usable by the current process.
    fmt.Println(runtime.NumCPU())
}
复制代码

我在个人本机上运行这个程序，NumCPU()方法会返回8，我在本机上跑的任何Go程序会分配8个逻辑处理器(P)。

每一个P会分配一个OS线程（M）。M表明机器(machine)。这个线程是OS来处理的而且OS还负责把线程放置到一个core上去执行。这意味着当我跑一个Go程序在个人机器上，我有8个可用的线程去执行个人工做，每一个线程单独连到一个P上。

每一个Go程序同时也会有一个初始的Goroutine（G）。一个Goroutine本质上是一个协程（Coroutine），可是在go里，把字面“C”替换为“G”因此咱们叫Goroutine。你能够认为Goroutine是一个用户程序级别的线程并且它跟OS线程不少方面都相似。区别仅仅是OS线程在内核(Core)上进行上下文切换（换上和换下）,而Goroutines是在M上。

最后一个让人困惑的就是运行队列。在Go 调度器中有两种不一样的运行队列：全局运行队列（GRQ）和本地运行队列(LRQ)。每一个P会分配一个LRQ去处理P的上下文要执行的Goroutines 。这些Goroutines会在绑定到P的M上进行上下文的切换。GRQ会处理尚未分配到P上的Goroutines 。Goroutines从GRQ挪到LRQ的过程一会咱们一下子会说。

图2.2是包含了全部相关组件的一张图片

图2.2

协做调度

咱们在第一部分的内容讲到了，OS调度器是一个抢占式调度器。也就是说你不知道调度器下一步会执行什么。内核所作的决定都是不肯定的。运行在OS顶层的应用程序没法控制内核里面的调度，除非你使用同步的原始操做，例如atomic指令和mutex调用

Go调度器是Go runtime的一部分，Go runtime会编译到你应用程序里。这意味着Go调度器运行在内核之上的用户空间(user space)

当前Go调度器采用的不是抢占式调度器，而是协做试调度器。协做试调度器，意味着调度器须要代码中安全点处发生的定义好的用户空间事件去作出调度决策。

Go的协做调度有一个很是棒的地方就是，它看上去像是抢占式的。你没办法预测Go调度器将要作什么，这是由于协做试调度器的决策不是开发人员而是go runtime去作的。将Go调度器看作是一个抢占式调度器是很重要的，由于调度是不肯定的，这里不须要再过多延伸。

Goroutine状态

和线程同样。Goroutine有三种相同的高级状态。Goroutine能够是任何一种状态：等待（Waiting）、可执行（Runnable）、运行中（Executing）.

等待：此时Goroutine已经中止而且等待事件发生来去再次执行。这多是出于等待操做系统（系统调用）或同步调用（原子操做atomic和互斥操做mutex）等缘由。 这些类型的延迟是性能不佳的根本缘由。

可执行： 此时Goroutine想要在M上执行分配给它的指令。若是有不少Goroutines想要M上的时间片，那么Goroutines必须等待更长时间。并且，随着更多Goroutines争夺时间片，单独Goroutines分配的时间就会缩短，这种类型的调度延时也会致使性能不好。

运行中：这意味着Goroutines已经放置在M上而且执行它的指令。此时应用程序的工做即将完成，这是咱们想要的状态。

上下文切换（Context Switching）

Go调度程序须要明肯定义的用户空间事件，这些事件发生在代码中的安全点以进行上下文切换。这些事件和安全点在函数调用时发生。函数调用对Go调度器的运行情况相当重要。Go 1.11 或者更低版本中，若是你跑一个不作函数调用的死循环，会致使调度器延时和垃圾回收延时。合理的时机使用函数调用十分重要。

注意：相关issue和建议已经被提出来，而且应用到了1.12版本中。应用非协做的抢占式技术，使得在tight loop中进行抢占。

Go程序中有4种类型的事件，容许调度器去作出调度决策。这不意味着某一个事件老是会发生，而是说调度器有机会去作出调度。

• 使用关键字 go
• 垃圾回收
• 系统调用
• 同步处理

使用关键字 go

使用关键字go来建立Goroutine。一旦一个新的Goroutine建立好，调度器便有机会去作出调度决定

垃圾回收

GC时候会有它本身的Goroutines，这些Goroutines也须要M上的时间片。这会致使GC产生不少调度混乱。可是调度器很聪明，它知道Goroutines在作什么，而后会作出合理的调度决策。一个聪明的决定就是对那些想要触及到堆的Goroutine和GC时候不会触及堆的Goroutine进行上下文切换。GC发生的时候会产生不少调度决策。

系统调用

若是一个Goroutine作出了会致使M阻塞的系统调用，调度器有时候会用一个新的Goroutine从M上替换下这个Goroutine。可是有时候会须要一个新的M去执行挂在P队列上的Goroutine，这种状况我会在下一部分讲解。

同步处理

若是atomic、mutex或者是channel操做的调用致使了Goroutine的阻塞，调度器会切换一个新的Goroutine去执行。一旦那个Goroutine又能够从新执行了，他会被挂到队列上并最终在M上会上下文切换回去。

异步系统调用

当OS有能力去处理异步的系统调用时候，使用网络轮询器(network poller)去处理系统调用会更加高效。不一样的操做系统分别使用了kqueue (MacOS)、epoll (Linux) 、 iocp (Windows) 对此做了实现。

今天许多操做系统都能处理基于网络(Networking-based)的系统调用。这也是网络轮询器(network poller)这一名字的由来，由于它的主要用途就是处理网络操做。网络系统上经过使用network poller，调度器能够防止Goroutines在系统调用的时候阻塞M。这可让M可以去执行其余在P的 LRQ上面的其余Goroutines而不是再去新建一个M。这能够减小OS上的调度加载。

最好的方式就是给一个例子看看它是如何工做的。

图2.3

图2.3展现了基本的调用图例。Goroutine-1正在M上面执行而且有3个Goroutine在LRQ上等待想要获取M的时间片。network poller此时空闲没事作。

图2.4

图2.4中 Goroutine-1想要进行network system调用，所以Goroutine-1移到了network poller上面而后处理异步调用，一旦Goroutine-1从M上移到network poller，M即可以去执行其余LRQ上的Goroutine。此时 Goroutine-2切换到了M上面。

图2.5

图2.5中，network poller的异步网络调用完成而且Goroutine-1回到了P的LRQ上面。一旦Goroutine-1可以切换回M上，Go的相关代码便可以再次执行。很大好处是，在执行network system调用时候，咱们不须要其余额外的M。network poller有一个OS线程可以有效的处理事件循环。

同步系统调用

当Goroutine想进行系统调用没法异步进行该怎么办呢？这种状况下，没法使用 network poller而且Goroutine产生的系统调用会阻塞M。很不幸可是咱们没法阻止这种状况发生。一个例子就是基于文件的系统调用。若是你使用CGO，当你调用C函数的时候也会有其余状况发生会阻塞M。

注意：Windows操做系统确实有能力去异步进行基于文件的系统调用。从技术上讲，在Windows上运行时可使用network poller。

咱们看一下同步系统调用(好比file I/O)阻塞M的时候会发生什么。

图2.6

图2.6又一次展现了咱们的基本调度图例。可是这一次Goroutine-1的同步系统调用会阻塞M1

图2.7

图2.7中，调度器可以肯定Goroutine-1已经阻塞了M。这时，调度器会从P上拿下来M1，Goroutine-1依旧在M1上。而后调度器会拿来一个新的M2去服务P。此时LRQ上的Goroutine-2会上下文切换到M2上。若是已经有一个可用的M了，那么直接用它会比新建一个M要更快。

图2.8

图2.8中，Goroutine-1的阻塞系统调用结束了。此时Goroutine-1可以回到LRQ的后面而且可以从新被P执行。M1以后会被放置一边供将来相似的状况使用。

工做窃取（Work Stealing）

调度器的另外一个层面，它其实也是一个work-stealing的调度器。这在一些状况下可以让调度更有效率。你最不想看到的事情是一个M进入了等待状态，由于这一旦发生，OS将会把M从core上切换下来。这意味着即便有可执行的Goroutine， P此时也无法干活了，直到M从新切换回core上。Work stealing同时也会平衡P上的全部Goroutines从而可以使工做更好的分配，更有效率。

让咱们看一个例子

图2.9

图2.9里，咱们有个多线程的Go程序。两个P分别服务4个Goroutines。而且一个单独的Goroutine在GRQ上。那么若是其中一个P很快执行完它全部的Goroutines会怎么样？

图2.10

P1没有更多Goroutine去执行了，可是在GRQ和P2的LRQ中都有可执行的Goroutines。这种状况P1会去窃取工做，Work Stealing的规则以下

L2

runtime.schedule() {
    // only 1/61 of the time, check the global runnable queue for a G.
    // if not found, check the local queue.
    // if not found,
    //     try to steal from other Ps.
    //     if not, check the global runnable queue.
    //     if not found, poll network.
}
复制代码

因此基于L2的规则，P1须要去看P2的LRQ上的Goroutines而且拿走一半。

图2.11

图2.11中，一半的Goroutines从P2上偷走，P1如今能够执行那些Goroutines

若是P2完成了全部Goroutines的执行，而且P1的LRQ上已经空了会怎么样？

图2.12

图2.12中，P2完成了它全部的工做，如今想要偷点什么。首先，它会去看P1的LRQ却发现什么也没有了。接下来他会去看GRQ。他会找到Goroutine-9

图2.13

图2.13中，P2从GRQ上偷走了Goroutine-9而且开始执行它的工做。这种work stealing的很大好处是，它让M一直有事情作而不是闲下来。这种work stealing 能够看作内部的M的轮转，这种轮转的好处在这篇博客里作了很好的解释。

实际例子

我想让你看一下Go调度器为了在同一时间里作更多事情，这一切是如何一块发生的。首先想象这样一个多线程的C语言应用，程序须要处理两个OS线程，他们俩互相进行通讯。

图2.14

图2.14中，有两个线程，相互通讯。线程1上下文切换到Core1上而且如今正在执行，这容许线程1向线程2发送消息。

注意：通讯方式不重要。重要的是这个过程里的线程状态。

图2.15

在图2.15中，一旦线程1完成发送消息，它就须要等待响应。这会致使线程1从Core1切换下来并处于等待状态。一旦线程2收到消息通知，它就会进入可执行的状态。如今OS进行上下文切换而后线程2在一个Core2上面执行。接下来线程2处理消息而后给线程1发送一个新消息。

图2.16

图2.16里。随着线程1收到线程2的消息，又一次发生了上下文切换。如今线程2从执行中的状态切换为等待的状态。而且线程1从等待状态切换到了可执行状态，最终回到运行状态。如今线程1能够处理并发送一个新消息回去。

全部的上下文切换(context switches)和状态的改变都须要花费时间去处理，这就限制了工做速度。每一次上下文切换 会致使50ns的潜在延迟，硬件执行指令的指望时间是每ns 12个指令，你会看到上下文切换的时候就少执行600个指令。由于这些线程在不一样的core以前切来切去，cache-line未命中致使的延迟也会增长。

咱们来看一下相同例子，使用Goroutines和Go调度器作替换。

图2.17

图2.17中，有两个Goroutines相互传递消息。G1上下文切换到M1上进行工做处理，以前这都是在Core1上发生的事情。如今是G1向G2发送消息。

图2.18

图2.18中，一旦G1发送完消息，它就会等待响应返回。这会让G1从M1上切换下来，而且进入到等到状态。一旦G2收到消息通知，它会进入可执行状态。如今Go调度器会把G2切换到M1上去执行，M1依旧在Core1上跑着。接下来G2处理消息而后给G1发送一个新消息。

图2.19

在图2.19中，随着G1收到G2发送来的消息，又一次发生上下文切换。如今G2从执行中的状态切换到等待状态而且G1从等待中切换到可执行状态，最终回到运行的状态，G1又可以处理并向G2发送新的消息了。

表面上事情并无什么不一样。不论你使用线程仍是Goroutines都有上下文切换和状态改变的过程。可是线程和Goroutines之间有一个重要的差异可能不会被明显注意到。

在使用Goroutines的场景，整个过程一直使用的是相同的OS线程和Core。这也就意味着，从OS的视角，OS线程历来没有进入到waiting状态，一次也没有。结果就是咱们在线程中上下文切换丢失的指令在Goroutines中不会丢失。

本质上讲，在OS层级go把io/blocking类型的工做转变成了cpu密集型的工做。因为全部上下文切换的过程都发生在应用程序的级别，上下文切换不会像线程同样丢掉600个指令（平均来讲）。Go调度器还有助于提升cache-line的效率和NUMA。这也是为何咱们不须要比虚拟内核数更多的线程。在Go里，随着时间推移更多事情会被处理，由于Go调度器会尝试用更少的线程而且每一个线程去作更多事情，这有助于减小OS和硬件层级的加载延迟。

结论

Go调度程序的设计在考虑操做系统和硬件工做复杂性方面确实使人惊讶。 在操做系统级别将IO /blocking工做转换为CPU密集型工做，是在利用更多CPU容量的过程当中得到巨大成功的地方。 这就是为何你不须要比虚拟内核数更多的OS线程。 每一个虚拟内核一个OS线程状况下，你能够合理的指望你的全部工做(CPU密集、IO密集)都可以完成。对于网络程序和那些不须要系统调用阻塞OS线程的程序，也可以完成。

做为开发人员，你依旧须要理解在处理不一样类型工做的时候你的程序正在作什么。你不能为了想要更好性能去无限制建立goroutine。Less is always more，可是经过理解了go调度器，你能够更好的作出决定。下一部分，我会探讨以保守的方式利用并发来提高性能的方法，可是对于代码的复杂性仍是要作出平衡。

原文连接：www.ardanlabs.com/blog/2018/0…