译: https://dave.cheney.net/2013/06/02/why-is-a-goroutines-stack-infinite
预备知识
想要理解这篇文章前,你可能需要了解计算机的内存模型。
1.内存模型Heap
程序运行的时候,操作系统会给它分配一段内存,用来储存程序和运行产生的数据。这段内存有起始地址和结束地址,比如从0x1000到0x8000,起始地址是较小的那个地址,结束地址是较大的那个地址。
程序运行过程中,对于动态的内存占用请求(比如新建对象,或者使用malloc命令),系统就会从预先分配好的那段内存之中,划出一部分给用户,具体规则是从起始地址开始划分(实际上,起始地址会有一段静态数据,这里忽略)。举例来说,用户要求得到10个字节内存,那么从起始地址0x1000开始给他分配,一直分配到地址0x100A,如果再要求得到22个字节,那么就分配到0x1020。
这种因为用户主动请求而划分出来的内存区域,叫做 Heap(堆)。它由起始地址开始,从低位(地址)向高位(地址)增长。Heap 的一个重要特点就是不会自动消失,必须手动释放,或者由垃圾回收机制来回收。
2.内存模型Stack
除了 Heap 以外,其他的内存占用叫做 Stack(栈)。简单说,Stack 是由于函数运行而临时占用的内存区域。
请看下面的例子。
func main() {
a := 2;
b := 3;
}
上面代码中,系统开始执行main函数时,会为它在内存里面建立一个帧(frame),所有main的内部变量(比如a和b)都保存在这个帧里面。main函数执行结束后,该帧就会被回收,释放所有的内部变量,不再占用空间。
如果函数内部调用了其他函数,会发生什么情况?
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。一般来说,调用栈有多少层,就有多少帧。
等到add_a_and_b运行结束,它的帧就会被回收,系统会回到函数main刚才中断执行的地方,继续往下执行。通过这种机制,就实现了函数的层层调用,并且每一层都能使用自己的本地变量。
所有的帧都存放在 Stack,由于帧是一层层叠加的,所以 Stack 叫做栈。生成新的帧,叫做"入栈",英文是 push;栈的回收叫做"出栈",英文是 pop。Stack 的特点就是,最晚入栈的帧最早出栈(因为最内层的函数调用,最先结束运行),这就叫做"后进先出"的数据结构。每一次函数执行结束,就自动释放一个帧,所有函数执行结束,整个 Stack 就都释放了。
Stack 是由内存区域的结束地址开始,从高位(地址)向低位(地址)分配。比如,内存区域的结束地址是0x8000,第一帧假定是16字节,那么下一次分配的地址就会从0x7FF0开始;第二帧假定需要64字节,那么地址就会移动到0x7FB0。
正文
偶然情况下发现了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
但尚未找到一个不会对正确编写的程序造成性能损失的解决方案。