Why is a Goroutine’s stack infinite ? （为什么goroutine的栈内存是无穷大的）？

译： https://dave.cheney.net/2013/06/02/why-is-a-goroutines-stack-infinite

预备知识

   想要理解这篇文章前，你可能需要了解计算机的内存模型。

1.内存模型Heap

  程序运行的时候，操作系统会给它分配一段内存，用来储存程序和运行产生的数据。这段内存有起始地址和结束地址，比如从0x1000到0x8000，起始地址是较小的那个地址，结束地址是较大的那个地址。

Heap.png

   程序运行过程中，对于动态的内存占用请求（比如新建对象，或者使用malloc命令），系统就会从预先分配好的那段内存之中，划出一部分给用户，具体规则是从起始地址开始划分（实际上，起始地址会有一段静态数据，这里忽略）。举例来说，用户要求得到10个字节内存，那么从起始地址0x1000开始给他分配，一直分配到地址0x100A，如果再要求得到22个字节，那么就分配到0x1020。

image.png

   这种因为用户主动请求而划分出来的内存区域，叫做 Heap（堆）。它由起始地址开始，从低位（地址）向高位（地址）增长。Heap 的一个重要特点就是不会自动消失，必须手动释放，或者由垃圾回收机制来回收。

2.内存模型Stack

  除了 Heap 以外，其他的内存占用叫做 Stack（栈）。简单说，Stack 是由于函数运行而临时占用的内存区域。

stack.png

请看下面的例子。

func main() {
    a := 2;
    b := 3;
}

  上面代码中，系统开始执行main函数时，会为它在内存里面建立一个帧（frame），所有main的内部变量（比如a和b）都保存在这个帧里面。main函数执行结束后，该帧就会被回收，释放所有的内部变量，不再占用空间。

image.png

如果函数内部调用了其他函数，会发生什么情况？

func main() {
    a := 2;
    b := 3;
   add_a_and_b(a,b);
}

  上上面代码中，main函数内部调用了add_a_and_b函数。执行到这一行的时候，系统也会为add_a_and_b新建一个帧，用来储存它的内部变量。也就是说，此时同时存在两个帧：main和add_a_and_b。一般来说，调用栈有多少层，就有多少帧。

image.png

  等到add_a_and_b运行结束，它的帧就会被回收，系统会回到函数main刚才中断执行的地方，继续往下执行。通过这种机制，就实现了函数的层层调用，并且每一层都能使用自己的本地变量。

  所有的帧都存放在 Stack，由于帧是一层层叠加的，所以 Stack 叫做栈。生成新的帧，叫做"入栈"，英文是 push；栈的回收叫做"出栈"，英文是 pop。Stack 的特点就是，最晚入栈的帧最早出栈（因为最内层的函数调用，最先结束运行），这就叫做"后进先出"的数据结构。每一次函数执行结束，就自动释放一个帧，所有函数执行结束，整个 Stack 就都释放了。

image.png

  Stack 是由内存区域的结束地址开始，从高位（地址）向低位（地址）分配。比如，内存区域的结束地址是0x8000，第一帧假定是16字节，那么下一次分配的地址就会从0x7FF0开始；第二帧假定需要64字节，那么地址就会移动到0x7FB0。

image.png

正文

  偶然情况下发现了golang一个奇怪的特性，这个特性与一个goroutine可用栈的数量有关。这个情况出现在当程序调用了一个无限递归的函数。为了理解这种情况下，请看下面的例子：

package main

import "fmt"

type S struct {
        a, b int
}

// String implements the fmt.Stringer interface
func (s *S) String() string {
        return fmt.Sprintf("%s", s) // Sprintf will call s.String()
}

func main() {
        s := &S{a: 1, b: 2}
        fmt.Println(s)
}

  不建议运行这个例子，当你运行时，你会发现你的机器会变得特别卡，甚至可能没响应，除非你在事情可以拯救前关闭程序。

  很多其他程序语言在调用无限递归循环时，程序会崩溃，但机器不会崩溃。为什么go语言不一样呢？

  goroutine有一个重要的特性是它们的消耗：goroutine创建时在初始内存方面的占用很小（不是传统的POSIX线程的1到8兆字节），在必要时栈内存会扩大或者收缩。这个特性允许goroutine创建时只有4096字节的栈内存，然后在有空余内存的情况下，必要时扩大或收缩

  为了实现这一点，链接器在每个函数的开始处插入小的前导码,检查该函数所需的栈数量是否低于当前可用的数量。如果超出了，调用runtime⋅morestack，它会分配一个新的堆栈页面，从调用者复制参数，然后将控制返回到原始函数，该函数现在可以安全地执行。当该函数退出时，该过程被撤消，其返回参数被复制回调用者的堆栈帧并释放不需要的堆栈空间。

  通过这个过程，栈内存实际上是无限的，并且假设你不是一直跨越两个栈之间的边界，通常称为栈拆分，这种消耗是比较小的。

  但是到目前为止一个细节没提到，它将意外使用递归函数与操作系统的严重内存耗尽情况联系起来，也就是说，当需要新的栈页面时，它们是从堆中分配的。

  当您的函数无限次调用自身时，将从堆中分配新的栈页面，允许该函数继续一遍又一遍地调用自身。 相当快的堆大小将超过机器中的可用物理内存量，此时交换将很快使您的机器无法使用。

  Go程序可用的堆大小取决于很多东西，包括CPU和操作系统的体系结构，但它通常表示超出机器物理内存的内存量，因此您的机器很可能 在你的程序耗尽它的堆之前大量交换。

  在Go 1.1中，有强烈的诉求说要增加32位和64位平台的堆的最大大小，这在一定程度上加剧了这个问题，即你不太可能拥有128Gb3的物理内存的系统。

  关于这个问题已经有几个open的issues
  https://github.com/golang/go/issues/4692
  https://github.com/golang/go/issues/2556
  但尚未找到一个不会对正确编写的程序造成性能损失的解决方案。