第 14 章执行栈管理 on Go 语言原本

14.1 连续栈的设计

Mon, 01 Jan 0001 00:00:00 +0000

14.1 连续栈的设计

每个 goroutine 都带着一个执行栈。它存放着函数调用的局部变量、参数、返回地址，是程序得以「正在执行」的物理载体。读者熟悉的 C 程序里，这个栈由操作系统线程提供，大小在线程创建时一次确定（ulimit -s 默认常是 8MB），此后不再变化。Go 走了另一条路：goroutine 的栈不是线程栈，而是运行时在堆上分配、自己管理、可以伸缩的一段内存，初始仅 2KB。

这条设计选择不是细节，它是 goroutine 能够「便宜到可以开成千上万个」的前提（9.3）。本节先把栈在运行时里的形态讲清楚：它由哪几个字段描述、stackguard0 如何在每个函数序言里守住栈底，再回到历史，看 Go 为什么从早年的分段栈（segmented stack）切换到今天的连续栈（contiguous stack），以及这次切换换来了什么、付出了什么。栈的分配、拷贝与收缩等机制留给本章后续各节，这里只谈设计。

14.1.1 栈在运行时里的形态

一个 goroutine 由一个 g 对象描述，它的头几个字段就刻画了执行栈。栈的边界用一对地址表示，区间是半开的 [lo, hi)，两端没有任何隐式的元数据：

1
2
3
4
5


// stack 描述一段栈内存，边界恰为 [lo, hi)，两侧无隐式结构（速写）
type stack struct {
 lo uintptr // 栈的低地址端（栈向低地址生长，lo 是「栈底极限」）
 hi uintptr // 栈的高地址端（最初的栈顶）
}

栈向低地址方向生长：函数调用压栈时，栈指针 SP 从 hi 一侧朝 lo 移动。lo 因此是这段栈所能用到的最低地址，越过它就是栈溢出。

14.2 栈的分配与缓存

Mon, 01 Jan 0001 00:00:00 +0000

14.2 栈的分配与缓存

本节内容对标 Go 1.26。

14.1 把执行栈定位为一段 [lo, hi) 的连续内存：它由运行时管理，本质上落在堆里，所以每个 Goroutine 一启动就要先有人给它划出这段地址。问题随之而来：谁来划？划多大？划完之后反复创建、销毁 Goroutine，这些两三 KB 的小块内存如果每次都直接找操作系统或全局堆去要，锁与系统调用的代价会立刻压垮调度。

答案是栈有它自己的一套分配器。它与 12 内存分配器不是同一套代码，却几乎是同一张设计图：每 P 无锁缓存在前，全局加锁仓库在后，堆与操作系统垫底。读过 12.2 的读者会发现，这一层不过是把 mcache / mcentral / mheap 的招式照搬到了栈上。本节先讲清这套并行结构长什么样，再说清它为何要与对象分配分开、又如何与垃圾回收衔接。

14.2.1 为什么栈要有自己的分配器

把栈交给通用对象分配器，初看是省事的，可栈有三条与普通对象不同的性质，逼着运行时另起一套。

其一，尺寸高度规整。Go 的栈最小 2KB（stackMin = 2048），每次伸缩都按 2 的幂翻倍（14.3），于是绝大多数栈只会是 2K / 4K / 8K / 16K 这几种大小。规整的尺寸天然适合用自由表（free list，12.2.1）按尺寸分桶管理，连尺寸类的查表都省了，一次移位就能算出该去哪个桶。

其二，生命周期与回收方式特殊。栈不像普通对象那样被指针图引用、靠标记存活，它的存活与对应的 Goroutine 绑定。栈内存被标成 mSpanManual 状态（手动管理），不参与 GC 的标记清扫，而是在栈收缩或 Goroutine 死亡时由运行时显式归还（14.5）。把这类「手动管理」的内存与「自动回收」的对象内存分开放，回收逻辑才干净。

其三，分配频率极高且在系统栈上。stackalloc 必须跑在调度栈（g0）上，因为它自己绝不能再触发栈增长，否则会死锁（runtime issue 1547）。这条约束要求分配路径短、不可重入，更不能在热路径上动辄加锁。

14.3 栈的增长

Mon, 01 Jan 0001 00:00:00 +0000

14.3 栈的增长

14.1 交代了 Go 选择连续栈的理由：栈起步只有 2KB，溢出时换一块两倍大的新栈，把旧栈整个拷过去。这一节只回答其中一个问题：运行时是怎么在「正确的时刻」知道栈快满了，又是怎么把控制权一路交到那段负责扩容的代码手里的。栈拷贝本身的细节留到 14.4。

困难在于，栈增长这件事必须在栈快要溢出、却还没真正溢出的瞬间发生，而触发它的又恰恰是普通的函数调用。换言之，每一次进入函数都要先问一句「我这一帧放得下吗」，放不下才去扩容。这道检查不能靠程序员手写，它由编译器在每个函数的开头自动埋下，这就是函数序言（prologue）里的分段检查。整条链路是：序言检查 → morestack（汇编）→ newstack（Go）→ copystack → 返回原处继续执行。我们顺着这条链走一遍。

14.3.1 函数序言：每次调用都先问一句

每个 Goroutine 的 g 结构里有一个字段 stackguard0，它是「栈还能用到哪里」的警戒线（2.2）。正常情况下它等于 stack.lo + stackGuard，即栈底再抬高一个保护区的位置。函数序言要做的，就是拿当前的栈指针 SP 和这条警戒线比较：栈向低地址生长，一旦 SP 跌到 stackguard0 之下，就说明剩余空间不足以容纳即将压入的这一帧，必须先扩容。

编译器并不会对所有函数都生成同样的检查。帧越大，越要把帧本身的大小算进去，于是检查分三档（常量 StackSmall = 128、StackBig = 4096 见 internal/abi/stack.go）。下面是 amd64 上序言的伪汇编，对应 cmd/internal/obj/x86/obj6.go 里的 stacksplit：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


// 小帧 framesize <= StackSmall：直接比较 SP 与警戒线
 CMPQ SP, stackguard0 // SP 是否已跌破警戒线？
 JHI ok // SP 仍在警戒线之上，放得下，跳过
 CALL runtime·morestack(SB)
ok:

// 中帧 StackSmall < framesize <= StackBig：把帧大小一并算进去
 LEAQ -(framesize-StackSmall)(SP), AX
 CMPQ AX, stackguard0
 JHI ok
 CALL runtime·morestack(SB)

// 大帧 framesize > StackBig：还要防 SP 接近 0 时的回绕（wraparound），
// 并显式检查警戒线是否被改成了 stackPreempt 这种「故意大于任何真实 SP」的值

警戒线被读成内存操作数 stackguard0，它在 g 中的偏移恰是第 3 个字（前两个字是 stack.lo、stack.hi），所以汇编里写作 2*PtrSize 处；C 函数则比对 stackguard1 （第 4 个字）。被 //go:nosplit 标记的函数不插入这段检查，代价是它们的帧必须挤进栈底那块 stackGuard - StackSmall 的保留区里，链接器会遍历所有不分段函数的调用链，确保这块预留够用。

14.4 栈的拷贝与指针调整

Mon, 01 Jan 0001 00:00:00 +0000

14.4 栈的拷贝与指针调整

连续栈的代价集中在一处：当一个 goroutine 的栈溢出，运行时分配一段两倍大的新栈，把旧栈整个搬过去，再释放旧栈。搬家这一步看似就是一次 memmove，把 [old.lo, old.hi) 的字节复制到 [new.lo, new.hi)。倘若真的只是复制字节，问题就来了：栈上的变量里可能存着指向这个栈自身的指针，比如某个局部变量取了另一个局部变量的地址。字节被原样搬到新地址后，这些指针的值没有变，仍然指着旧栈的位置，而旧栈马上就要被回收。复制完成的那一刻，它们就成了悬垂指针。

所以栈的拷贝不是 memmove，而是 memmove 加上一遍指针调整：搬完字节之后，运行时必须遍历新栈，把每一个原本指向旧栈区间的指针，统统加上一个固定的位移 $\delta = \mathrm{new.hi} - \mathrm{old.hi}$，让它改指向新栈的对应位置。难点不在「怎么加」，而在「怎么知道哪些字是指针」。栈上的字没有类型标签，一个 8 字节的字到底是指针还是恰好长得像地址的整数，运行时无从分辨。答案来自编译器：它为每个函数在每个安全点（13.7）生成了栈映射 （stack map），用位图精确记录该函数栈帧里哪些槽位是指针。GC 扫描栈靠它，栈拷贝调整指针也靠它。

这一节就讲这件事：copystack 如何在搬家之后，借栈映射走遍新栈，把所有指向旧栈的指针、加上那些不在栈帧里、却同样指向栈的运行时结构（gobuf、sudog、defer、panic）一并调整正确。读完会看到，正是「栈可以移动」这条性质，反过来约束了语言：哪些指针允许指向栈、逃逸分析（15.5）为何必须把外部持有的地址搬到堆上。

14.4.1 为什么不能只 memmove

先把问题摆清楚。考虑一段普通的 Go 代码：

1
2
3
4
5


func f() {
	var x int
	p := &x // p 指向本栈帧里的 x
	g(p) // 把栈上地址传下去
}

p 的值是 x 在栈上的地址，落在 [old.lo, old.hi) 区间内。当 g 或其更深的调用触发栈增长，整个栈被搬到新地址，x 随之搬走，但 p 这个字里存的还是旧地址。若不修正，p 指向的已是一段即将释放、或将被别的 goroutine 栈复用的内存。

14.5 栈的收缩与演进

Mon, 01 Jan 0001 00:00:00 +0000

14.5 栈的收缩与演进

14.4 讲的是栈的「长大」：当函数序言（prologue）发现栈快要用尽，运行时把整段栈拷贝到一块更大的内存上，栈指针随之平移。这是一条由执行本身驱动的单向力，它只会让栈越来越大。可是一个 goroutine 的栈深并不单调。一段递归走到很深，再层层返回到浅处，它真正需要的栈早已缩回，但那块为深递归而扩出的大栈仍挂在它名下。若只有增长没有归还，每个 goroutine 的栈最终都会停在它历史上的最深点。对一个动辄持有百万 goroutine 的程序，这笔账无法承受。

所以栈也会「缩小」。增长由序言触发，发生在执行的热路径上；收缩则交给垃圾回收，在扫描栈的间隙顺手完成。两股力一推一收，让每个 goroutine 的栈始终贴着它当下的真实需要。这一节先看收缩的时机与判据，再说清这套「自我调节」为何是轻量并发的地基，最后把它放回语言演进与跨系统的坐标里。

14.5.1 收缩的时机与判据

收缩不是随时能做的。拷贝栈要改写栈上所有指向栈内的指针（14.4），这要求运行时此刻对该 goroutine 的栈拥有精确的指针信息，并且没有别的执行流正踩在这段栈上。能同时满足这两点的最自然的窗口，正是垃圾回收扫描栈的时候：GC 为了标记存活对象，本就要停住每个 goroutine、逐帧扫描它的栈（13.4、13.7）。栈既然已经停稳、指针图也已备齐，扫描完顺手判断要不要收缩，几乎是零额外成本。

于是 shrinkstack 由 scanstack 调用。扫描在确认栈安全可缩后才动手；若当下不安全，就把意图记在 gp.preemptShrink 上，留到下一个同步安全点再补做：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// scanstack：GC 扫描某个 goroutine 的栈（节选自 runtime/mgcmark.go）
func scanstack(gp *g, gcw *gcWork) int64 {
 // ... 统计本次要扫描的栈大小，用于初始栈尺寸的自适应估计 ...
 if isShrinkStackSafe(gp) {
 shrinkstack(gp) // 不安全的窗口之外，顺手收缩
 } else {
 gp.preemptShrink = true // 否则推迟到下一个同步安全点
 }
 // ... 继续扫描栈帧，标记其中的指针 ...
}

什么叫「安全」？isShrinkStackSafe 把几类不能动栈的处境一一排除：goroutine 正陷在系统调用里（syscallsp != 0，系统调用可能持有指向栈的裸指针，且最内层栈帧没有精确指针图）；停在异步抢占的安全点上（同样缺精确指针图）；正处在「已调用 gopark 准备挂到 channel、但 activeStackChans 尚未置位」的窗口；以及为了配合 suspendG 而停在 _Gwaiting 的 goroutine。任何一条命中，本轮就不缩。

第 14 章 执行栈管理 on Go 语言原本

14.1 连续栈的设计

14.1 连续栈的设计

14.1.1 栈在运行时里的形态

14.2 栈的分配与缓存

14.2 栈的分配与缓存

14.2.1 为什么栈要有自己的分配器

14.3 栈的增长

14.3 栈的增长

14.3.1 函数序言：每次调用都先问一句

14.4 栈的拷贝与指针调整

14.4 栈的拷贝与指针调整

14.4.1 为什么不能只 memmove

14.5 栈的收缩与演进

14.5 栈的收缩与演进

14.5.1 收缩的时机与判据

第 14 章执行栈管理 on Go 语言原本