在golangweekly的第36期Go Newsletter中我发现一篇短文"How Goroutines Work" ，其作者在参考了诸多资料后，简短概要地总结了一下 Goroutine的工作原理，感觉十分适合刚入门的Gophers（深入理解Goroutine调度的话，可以参考Daniel Morsing的" The Go scheduler" )。这里粗译如下。

一、Go语言简介

如果你是Go语言新手，或如果你对"并发(Concurrency)不是并行(parallelism)"这句话毫无赶脚，那么请看一下Rob Pike大神关于这个主题的演讲吧，演讲共30分 钟，我敢保证你在这个演讲上花费30分钟是绝对值得的。

总结一下两者（Concurrency和Parallelism）的不同："当人们听到并发（Concurrency)这个词时，总是会想起并行 （Parallelism），它们之间有相关性，但却是两个明显不同的概念。在编程领域，并发（Concurrency）是独立的执行过程 (Process)的组合，而并行（Parallelism)则是计算（可能是相关联的）的同时执行。并发（Concurrency)是关于同时 应对很多事情(deal with lots of things)，而并行（Parallelism)则是同时做许多事情(do lots of things)"。(Rob Pike的“Concurrency is not parallelism")

Go语言支持我们编写并发(Concurrent)的程序。它提供了Goroutine以及更重要的在Goroutines之间通信的能力。这里 我们将聚焦在前者（译注：指并发）。

二、Goroutines和Threads

Goroutine是一个简单的模型：它是一个函数，与其他Goroutines并发执行且共享相同地址空间。Goroutines的通常用法是根据需要创建尽可 能的Groutines，成百上千甚至上万的。这种用法对于那些习惯了使用C++或Java的程序员来讲可能会有些奇怪。创建这么多 goroutines势必要付出不菲的代价？一个操作系统线程使用固定大小的内存作为它的执行栈，当线程数增多时，线程间切换的代价也是相当的 高。这也是每处理一个request就创建一个新线程的服务程序方案被诟病的原因。

不过Goroutine完全不同。它们由Go运行时初始化并调度，操作系统根本看不到Goroutine的存在。所有的goroutines都是 活着的，并且以多路复用的形式运行于操作系统为应用程序分配的少数几个线程上。创建一个Goroutine并不需要太多内存，只需要8K的栈空间 （在Go 1.3中这个Size发生了变化）。它们根据需要在堆上分配和释放内存以实现自身的增长。

Go运行时负责调度Goroutines。Goroutines的调度是协作式的，而线程不是。这意味着每次一个线程发生切换，你都需要保存/恢 复所有寄存器，包括16个通用寄存器、PC(程序计数器）、SP（栈指针）、段寄存器(segment register)、16个XMM寄存器、FP协处理器状态、X AVX寄存器以及所有MSR等。而当另一个Goroutine被调度时，只需要保存/恢复三个寄存器，分别是PC、SP和DX。Go调度器和任何现代操作 系统的调度器都是O(1)复杂度的，这意味着增加线程/goroutines的数量不会增加切换时间，但改变寄存器的代价是不可忽视的。

由于Goroutines的调度是协作式的，一个持续循环的goroutine会导致运行于同一线程上的其他goroutines“饿死”。在 Go 1.2中，这个问题或多或少可以通过在进入函数前间或地调用Go调度器来缓解一些，因此一个包含非内联函数调用的循环是可以被调度器抢占的。

三、Goroutine阻塞

只要阻塞存在，它在OS线程中就是不受欢迎的，因为你拥有的线程数量很少。如果你发现大量线程阻塞在网络操作或是Sleep操作上，那就是问题， 需要修正。正如前面提到的那样，Goroutine是廉价的。更关键地是，如果它们在网络输入操作、Sleep操作、Channel操作或 sync包的原语操作上阻塞了，也不会导致承载其多路复用的线程阻塞。如果一个goroutine在上述某个操作上阻塞，Go运行时会调度另外一 个goroutine。即使成千上万的Goroutine被创建了出来，如果它们阻塞在上述的某个操作上，也不会浪费系统资源。从操作系统的视角来看，你的程序的行为就像是一个事件驱动的C程序似的。

四、最后的想法

就是这样，Goroutines可以并发的运行。不过和其他语言一样，组织两个或更多goroutine同时访问共享资源是很重要的。最好采用Channel在不同Goroutine间传递数据。

最后，虽然你无法直接控制Go运行时创建的线程的数量，但可以通过调用runtime.GOMAXPROCS(n)方法设置变量GOMAXPROCS来设 定使用的处理器核的数量。提高使用的处理器核数未必能提升你的程序的性能，这取决于程序的设计。程序剖析诊断工具(profiling tool)可以用来检查你的程序使用处理器核数的真实情况。

Go 1.4Beta1刚刚发布，在Go 1.4Beta1中，Go语言的stack处理方式由之前的"segmented stacks"改为了"continuous stacks"。关于Go语言对stack的处理机制、发展历史、存在问题等，CloudFlare的一篇官方blog进行了系统的阐述，这里的内容就是 翻译自CloudFlare的那篇blog：《How Stacks are Handled in Go》。

在CloudFlare，我们使用Go语言实现各种服务和应用。在这篇博文中，我们将带领大家深入挖掘一些Go的某些纷繁复杂的技术细节。

Go语言的重要特性之一是goroutines。它们是代价低廉、协同调度的执行线程，被用于实现各种操作，诸如timeout、生成器、相互竞 争的后端程序。为了使goroutines可以适应更多地任务，我们不仅需要保证每个goroutines的内存最小占用量，还要保证人们可以使 用最低配置将它们启动起来。

为了实现这个目标，Go语言采用了栈管理，这一与其他编程语言类似的方案，但在具体实现层面，又与其他语言有着较大的不同。

一、线程栈(thread stacks)介绍

在我们研究Go的栈处理方式之前，我们先来看看传统语言，比如C是如何进行栈管理的。

当你启动一个C实现的thread时，C标准库会负责分配一块内存作为这个线程的栈。标准库分配这块内存，告诉内核它的位置并让内核处理这个线程 的执行。不过当这块内存不够用时，问题就来了，我们来看一下下面这个函数：

int a(int m, int n) {
    if (m == 0) {
        return n + 1;
    } else if (m > 0 && n == 0) {
        return a(m – 1, 1);
    } else {
        return a(m – 1, a(m, n – 1));
    }
}

这个函数大量使用递归，执行a(4, 5)就会降所有栈内存耗尽。要解决这个问题，你可以调整标准库给线程栈分配的内存块的大小。但是全线提高栈大小意味着每个线程都会提高栈的内存使用量，即 便它们不是大量采用递归方式的。这样一来，你将用光所有内存，即便你的程序还尚未使用栈上的内存。

另外一种可选的解决方法则是为每个线程单独确定栈大小。这样一来你就不得不完成这样的任务：根据每个线程的需要，估算它们的栈内存的大小。这将是 创建线程的难度超出我们的期望。想搞清楚一般情况下一个线程栈需要多少内存是不可行的，即便是通常情况也是非常困难的。

二、Go是如何应对这个问题的

Go运行时会试图按需为goroutine提供它们所需要的栈空间，而不是为每个goroutine分配一个固定大小的栈空间。这样可以把程序员 们从决定栈空间大小的烦心事中解脱了出来。不过Go核心团队正在尝试切换到另外一种方案，这里我将尝试阐述旧方案以及它的缺点，新方案以及为何要 做出如此改变。

三、分段栈(Segmented Stacks)

分段栈(segmented stacks)是Go语言最初用来处理栈的方案。当创建一个goroutine时，Go运行时会分配一段8K字节的内存用于栈供goroutine运行使 用，我们让goroutine在这个栈上完成其任务处理。

当我们用光这8K字节的栈空间后，问题随之而来。为了解决这个问题，每个go函数在函数入口处都会有一小段代码(called prologue)，这段代码会检查是否用光了已分配的栈空间，如果用光了，这段代码会调用morestack函数。

morestack函数会分配一段新内存用作栈空间，接下来它会将有关栈的各种数据信息写入栈底的一个struct中(译注：下图中Stack info)，包括上一段栈的地址。有点我们拥有了一个新的栈段(stack segment)，我们将重启goroutine，从导致栈空间用光的那个函数（译注：下图中的Foobar）开始执行。这就是所谓的“栈分裂 (stack split)”。

下面的栈示意图刚好是我们进行栈分裂后的情形：

在新栈的底部，我们插入了一个栈入口函数lessstack。我们不会调用该函数，设置这个函数就是用于我们从那个导致我们用光栈空间的函数(译 注：Foobar)返回时用的。当那个函数(译注：Foobar)返回时，我们回到lessstack（这个栈帧），lessstack会查找 stack底部的那个struct，并调整栈指针(stack pointer)，使得我们返回到前一段栈空间。这样做之后，我们就可以将这个新栈段(stack segment)释放掉，并继续执行我们的程序了。

四、分段栈(Segmented stacks)的问题

分段栈给了我们具备按需伸缩能力的栈。程序员们无需担心计算栈的大小了，启动一个新的goroutine代价低廉并且程序员不会知道栈将增长多 大。

这就是直到目前Go语言处理stack增长的方法，但是这个方法有个瑕疵。那就是栈缩小会是一个相对代价高昂的操作。如果你在一个循环遇到栈分裂 (stack split)，你会最有感触。一个函数会增加栈空间，做栈分裂，返回并释放栈段(stack segment)。如果你在一个循环中进行这些，你会付出很大的代价（性能方面）。

这就是所谓的“hot split”问题。它也是Go核心开发组更换到一个新的栈管理方案-栈拷贝(stack copying)的主要原因。

五、栈拷贝(stack copying)

栈拷贝初始阶段与分段栈类似。goroutine在栈上运行着，当用光栈空间，它遇到与旧方案中相同的栈溢出检查。但是与旧方案采用的保留一个返 回前一段栈的link不同，新方案创建一个两倍于原stack大小的新stack，并将旧栈拷贝到其中。这意味着当栈实际使用的空间缩小为原先的 大小时，go运行时不用做任何事情。栈缩小是一个无任何代价的操作。此外，当栈再次增长时，运行时也无需做任何事情，我们只需要重用之前分配的空 闲空间即可。

六、栈是怎么拷贝的

拷贝栈听起来简单，但实际上它是一件有难度的事情。因为Go中栈上的变量都有自己的地址，一旦你拥有指向栈上变量的指针，这种情况下你就无法如你 所愿。当你移动栈时，指向原栈的指针都将变为无效指针。

幸运的是，只有在栈上分配的指针才能指向栈上的地址。这点对于内存安全是极其必要的，否则，程序可能会访问到已不再使用了的栈上的地址。

由于我们需要知道那些需要被垃圾收集器回收的指针的位置，因此我们知道栈上哪些部分是指针。当我们移动栈时，我们可以更新栈里地指针使其指向新的 目标地址，并且所有相关的指针都要被照顾到。

由于我们使用垃圾回收的信息来协助完成栈拷贝，因此所有出现在栈上的函数都必须具备这些信息。但事情不总是这样的。因为Go运行时的大部分代码是 用C编写的，大量的运行时调用没有指针信息可用，这样就无法进行拷贝。一旦这种情况发生，我们又不得不退回到分段栈方案，并接受为其付出的高昂代 价。

这就是当前Go运行时开发者大规模重写Go runtime的原因。那些无法用Go重写的代码，比如调度器和垃圾收集器的内核，将在一个特殊的栈上执行，这个特殊栈的size由runtime开发者 单独计算确定。

除了让栈拷贝成为可能之外，这个方法还会使得我们在未来能够实现出并发垃圾回收等特性。

七、关于虚拟内存

另外一种不同的栈处理方式就是在虚拟内存中分配大内存段。由于物理内存只是在真正使用时才会被分配，因此看起来好似你可以分配一个大内存段并让操 作系统处理它。下面是这种方法的一些问题

首先，32位系统只能支持4G字节虚拟内存，并且应用只能用到其中的3G空间。由于同时运行百万goroutines的情况并不少见，因此你很可 能用光虚拟内存，即便我们假设每个goroutine的stack只有8K。

第二，然而我们可以在64位系统中分配大内存，它依赖于过量内存使用。所谓过量使用是指当你分配的内存大小超出物理内存大小时，依赖操作系统保证 在需要时能够分配出物理内存。然而，允许过量使用可能会导致一些风险。由于一些进程分配了超出机器物理内存大小的内存，如果这些进程使用更多内存 时，操作系统将不得不为它们补充分配内存。这会导致操作系统将一些内存段放入磁盘缓存，这常常会增加不可预测的处理延迟。正是考虑到这个原因，一 些新系统关闭了对过量使用的支持。

八、结论

为了使goroutine使用代价更加低廉，更快速，适合更多task情况，Go开发组做出了很多努力。栈管理只是其中一小部分。如果你想了解更 多关于栈拷贝的细节，可以参考其设计文档。此外，如果你想了解更多有关Go运行 时重写的细节，这里有一个mail list。