goroutine的调度

goroutine的调度

概述

Go 1.1 重要特性之一就是由 Dmitry Vyukov 贡献的新调度器。无需对程序进行任何调整，新的调度器就能够为 Go 程序带来使人兴奋的性能提高。所以我以为有必要就此写点什么。

在本博文所述的大多数内容都已经在原始的设计文档中有所介绍。那是一篇至关全面的文档，同时也至关专业。

你想要了解的关于新的调度器的一切都能在那篇文档里找到，而这篇博文描绘了总体状况，因此优略得所。

为何 Go 运行时须要一个调度器

在了解新调度器以前，先要了解为何须要它。为何在操做系统已经可以对线程进行调度的状况下还须要建立一个用户空间调度器。

POSIX 线程 API 绝对是对已有的 Unix 进程模型的逻辑扩展，这样线程就得到了跟进程相似的控制方式。线程拥有本身的信号掩码，能够与 CPU 关联起来，能够放入 cgroups 或查询哪些资源被其使用。全部这些控制方式所带来的特性对于使用 goroutine 的 Go 程序来讲都不须要，而且当程序有 100000 个线程的时候，所需的控制会急速膨胀。

另外一个问题是 OS 不能基于 Go 模型根据实际状况进行调度。例如，Go 垃圾收集器在执行回收时，须要全部的线程都先中止，而内存也必须在一致的状态。这包含了等待正在运行的线程执行到某个已知内存会达到一致状态的地方。

当有许多线程进行随机的调度，挑战是你必须不停的等待他们达到一致状态。 Go 调度器能够决定在已知内存会一致的地方进行调度。这意味着当停下进行垃圾收集时，只须要等待在 CPU 内核上实际运行的线程。

咱们的阵容

一般有三个线程模型。一个是 N:1，也就是若干个用户空间线程运行在一个 OS 线程上。它的好处是上下文切换很是迅速，而坏处是没法发挥多核系统。另外一个是 1:1，也就是一个执行线程对应一个 OS 线程。好处是能够利用机器上的全部内核，不过因为它是经过 OS 来进行的，因此上下文切换很是慢。

Go 试图利用 M:N 调度器在两个世界中找到平衡点。若干 goroutine 调度在若干 OS 线程上。获得了快速的上下文切换，而且能够利用系统里的全部核心。而主要的问题是这个方法会增长调度器的复杂度。

为了完成任务的调度，Go 调度器使用了 3 个主要的实体：

三角形表明 OS 线程。它是由系统管理执行的线程，而且工做方式与标准的 POSIX 线程至关相似。在运行时的代码里，叫作 M 表明设备。

圆形表明 goroutine。它包括了栈、指令指针和其余调度 goroutine 所需的重要信息，如可能阻塞它的任何一个 channel。在运行时代码里，它被叫作 G。

矩形表明调度的上下文。能够将其看做是一个在一个线程上运行 Go 代码的局部版本的调度器。这是从 N:1 调度器演化到 M:N 调度器的重要的一环。在运行时代码中，它被叫作 P 表明处理器。关于这部分还得再多说几句。

这里有 2 个线程（M），每一个都拥有一个上下文（P），每一个都执行一个 goroutine（G）。线程必须拥有一个上下文才能执行 goroutine。

**上下文的数量是由环境变量 GOMAXPROCS 在启动的时候设置的，也能够经过运行时函数 GOMAXPROCS() 设置。事实上上下文的数量是固定的，这也就是说任什么时候候都只有 GOMAXPROCS 个 Go 代码在执行。**可使用这个来在不一样的计算机上进行调整，好比 4 核 PC 会运行 4 条 Go 代码的线程。

灰色的 goroutine 没有在运行，可是已经准备好被调度了。它们排列在一个叫作 runqueues 的列表里。当 goroutine 执行 go 语句时就会被添加到 runquque 的尾部。一个正在运行的 goroutine 到达调度点时，上下文就会从 runqueue 中弹出这个 goroutine，而且设置栈和指令指针，而后开始执行下一个 goroutine。

为了减小互斥争用，每一个上下文都有它本身本地的 runqueue。上一个版本的 Go 调度器只有一个使用互斥量保护的全局 runqueue。线程常常为了等待互斥量解锁而被阻塞。当在一个 32 核的机器上想要尽量的压榨性能时这会变得很是糟糕。

只要上下文有 goroutine 须要运行，调度器就会在这个稳定的状态下持续的进行调度。然而，有一些状况可能会改变这个局面。

你要（系统）调用谁？

你如今可能在想，为何须要上下文？为何不能抛开上下文直接将 runqueue 放在线程上？其实不是这样的。有上下文的缘由是当因为某些缘由正在执行的线程会阻塞时能够切换到其余线程。

一个关于阻塞的例子就是系统调用。因为线程没法在运行代码的同时又阻塞在系统调用上，因此须要上下文进行切换来保证调度。

这里能够看到一个线程放弃了它的上下文，所以其余线程能够运行。调度器保证了有足够的线程运行全部的上下文。为了正确的处理系统调用，会建立或者是从线程缓存中获取上图中的 M1。技术上说被系统调用线程持有的进行了系统调用的 goroutine 仍然是在运行的，尽管在 OS 层它被阻塞了。

当系统调用返回，线程必须尝试获取上下文以便让 goroutine 继续运行。一般的模式是从其余线程窃取一个上下文。若是没办法偷获得，就会将 goroutine 放入全局 runqueue 中，而后本身返回线程缓存继续休眠。

当上下文执行完本地的 runqueue 后，会从全局 runqueue 获取 goroutine。上下文也会按期的检查全局 runqueue。不然的话在全局 runqueue 上的 goroutine 可能因为缺少资源而永远都不会运行。

这个处理系统调用的方法说明了为何即便 GOMAXPROCS 为 1 的时候，Go 程序也会运行多个线程。运行时用 goroutine 调用系统调用，而让线程藏在背后。

窃取工做

当一个上下文调度执行完全部的 goroutine 时系统的稳定状态也会发生变化。这发生在上下文的 runqueue 分配的工做不平衡的时候。这会致使当上下文清空其 runqueue 后，在系统中仍然有工做须要完成。为了让 Go 代码继续执行，上下文能够从全局 runqueue 获取 goroutine，可是若是没有 goroutine 在其中的话，总得从其余什么地方获取到它们。

这个其余地方其实就是其余上下文。当一个上下文执行完，它会试图偷取其余上下文的一半 runqueue。这保证了每一个上下文都老是有工做可作，也保证了全部的线程都进其最大的能力在工做。

何去何从？

还有许多调度器的细节，如 cgo 线程，LockOSThread() 函数和带有网络池的指令。它们不在本文讨论的范围内，可是仍然值得学习。之后我可能会写一些关于这些的内容。在 Go 运行时库中还有许许多多有趣的创造等待着被探索。