为什么 goroutine 初始栈只有 2KB
了解并发编程的人都知道，操作系统线程的栈通常是在创建时一次性分配好的，默认大小在 1MB 到 8MB 之间。如果按这个标准去设计 goroutine，那么一台机器只能同时运行几千个线程，远远满足不了 Go 追求的高并发模型。Go 的做法是给每个 goroutine 分配一个很小的初始栈，在 64 位平台上默认为 2KB。小栈的好处很明显：创建大量 goroutine 时内存成本很低，几万个 goroutine 加起来也不过几十 MB。
但这里有一个前提：2KB 只够容纳最简单的函数调用链。一旦函数嵌套变深，或者函数内部定义了较大的局部变量，2KB 就会迅速用完。因此 Go 必须在运行时为 goroutine 提供栈扩容能力。goroutine 栈增长机制由此而来，它也是理解 Go 内存模型时绕不开的一环。
从分段栈到连续栈：Go 的选择
Go 并不是一开始就采用连续栈方案。在 Go 1.3 之前，运行时使用的是分段栈。每个栈由多个独立的「段」组成，栈空间不足时就追加一个新段，并用链表连起来。这样做的好处是不用拷贝旧数据，但问题也很明显：当程序在段边界附近反复调用和返回时，会频繁触发段的创建和销毁，带来极大的运行时开销，社区把这个现象称为“热分裂”。
为了解决热分裂，Go 1.3 引入了连续栈。连续栈本质上是一段完整的堆内存，当栈空间不足时，运行时分配一块更大的内存，把旧栈整体拷贝到新栈中，然后释放旧栈。虽然拷贝本身有成本，但避免了热分裂，也简化了栈的管理。
栈扩容触发的真实时机
很多开发者以为栈是“用满了才扩容”，实际上 Go 在每次函数调用前都会检查一次栈空间。编译器会在函数入口插入一段汇编指令，比较 SP 寄存器和当前 goroutine 的 stack.lo 地址。如果 SP 已经低于 stack.lo，说明当前栈空间不足，就会调用运行时函数 morestack。整个检查过程只有几条指令，正常情况下对性能影响极小。
// 函数调用入口处的栈检查
if sp <= stack.lo {
call morestack
}
这里需要特别注意的是，go 关键字创建 goroutine 时，并不是在创建时就确定好栈大小，而是让每个 goroutine 在首次运行时都从 2KB 开始。随着调用深度增加，栈会按需成倍增长。每一次扩容都是新栈大小翻倍，例如 2KB -> 4KB -> 8KB -> 16KB……这样既减少了扩容次数，又避免浪费。
栈扩容的完整流程
当 morestack 被调用后，运行时会执行下面这些步骤：
- 计算新栈大小：默认使用当前栈大小的两倍，但不会超过最大栈限制。
- 在堆上分配一段连续内存作为新栈。
- 将旧栈中的所有数据复制到新栈。
- 遍历旧栈上的指针，将它们从旧地址调整为指向新栈中的对应位置。
- 更新 goroutine 的栈描述符，并释放旧栈。
其中指针修正这一步最需要警惕。程序员很容易在函数中取得某个局部变量的地址，把它作为参数传入其他函数，甚至保存在全局变量中。当栈被整体搬走后，这些指向旧栈的指针都会失效。Go 解决这个问题依靠的是编译器生成的栈帧信息。每个函数在编译时都会记录栈帧内哪些偏移量包含指针，运行时根据这些位图精确地调整每一个指针值。
正是由于需要精准修正指针，连续栈的拷贝过程必须“了解”栈上每个字的含义。这也是为什么 Go 对指针操作有严格限制，不允许随意做指针算术和类型转换。
栈收缩：回收大于实际需求的空间
如果只扩容不收缩，曾经深递归过的 goroutine 就会一直霸占大块内存。以高并发服务为例，一个处理请求的 goroutine 可能在某个阶段因为临时递归消耗了几百 KB 栈，如果这个空间永不释放，那么服务运行一段时间后内存就会消耗殆尽。
Go 的收缩策略和 GC 绑定。每次垃圾回收扫描栈时，运行时都会计算栈的使用率。如果已使用的栈空间不足当前栈总大小的四分之一，就把栈大小缩减一半，然后再次拷贝。这样既保证了不会频繁收缩，也避免了栈长期膨胀。
需要理解的是，栈收缩是有代价的，所以 Go 设定了一个比较保守的阈值，保证只有在明显浪费时才触发。另外，栈收缩只在 GC 期间进行，如果 GC 间隔较长，一个 goroutine 的膨胀栈可能会维持相当长时间。这也是实际项目中栈内存占用波动的核心原因。
三个容易踩的坑
- 坑一：认为 goroutine 栈大小固定。实际上它既会增长也会收缩，默认上限在 64 位系统上是 1GB。无限递归最终会触发 stack overflow，而不是无限增长。
- 坑二：在栈上放置超大的局部变量。比如在函数内声明一个 1MB 的数组，即使只使用一小部分，也会让栈立即膨胀到 1MB 以上。频繁调用这样的函数会带来不必要的拷贝开销。
- 坑三：忽略栈增长对 GC 的影响。GC 需要扫描所有 goroutine 的栈。栈越大，扫描成本越高。如果大量 goroutine 的栈都因为偶发递归变得很大，GC 停顿时间可能明显增加。
Go 栈与其他线程栈的对比
为了更直观理解 goroutine 栈的优势和限制，我整理了一张对比表：
| 对比项 | Go goroutine | OS 线程 | 无栈协程（如 C++20） |
|---|---|---|---|
| 初始栈大小 | 2KB | 一般 1-8MB | 无独立栈，状态保存在堆上 |
| 扩容方式 | 连续栈拷贝，按 2 倍增长 | 由操作系统决定，增长缓慢 | 不需要 |
| 收缩方式 | GC 时按使用率收缩一半 | 基本不收缩 | 不需要 |
| 最大栈大小 | 64 位默认 1GB | 由操作系统限制 | 受堆内存限制 |
| 切换成本 | 只需切换 goroutine 上下文 | 系统调用，成本较高 | 表现为函数调用，成本最低 |
从这个表格能看出，Go 的连续栈方案在“易用性”和“内存效率”之间做了很好的平衡。它保留了传统函数调用的编程模型，又能让大量轻量级协程共存。
如何观察 goroutine 栈占用
在实际项目中，如果你怀疑 goroutine 栈内存有问题，可以读取 runtime.MemStats 中的栈相关字段。
var m runtime.MemStats
runtime.ReadMemStats(&m)
fmt.Println("stack inuse:", m.StackInuse/1024/1024)
这段代码输出当前进程所有 goroutine 栈占用的 MB 数。如果这个值持续偏高，可以配合 pprof 分析具体哪个 goroutine 栈最大。使用 go tool pprof 可以抓取 goroutine 的堆栈信息，观察每个调用链的栈深度和内存占用。
优化建议：控制栈增长的关键
首先，避免在业务函数中定义极大的局部数组。如果确实需要一个大缓冲区，尽量使用 make 在堆上分配。编译器可能根据逃逸分析将大对象放到堆上，但如果你在函数里显式创建了 [64*1024]byte，它很可能会留在栈上，因为编译器认为它没有逃逸。这时候栈会立刻从 2KB 跳变到 64KB 甚至更大。
其次，注意递归深度。递归是栈增长的主要推手。如果业务上无法避免递归，可以尝试改用循环或迭代器。例如遍历文件树时，用显式栈代替递归可以保持 goroutine 栈不变。
最后，如果某些 goroutine 需要长期存在且拥有较大栈，可以考虑拆分成多个小 goroutine，或者显式调用 runtime.GC() 来触发收缩，但后者不推荐在生产环境使用，因为会阻塞所有任务。
小结
goroutine 的连续栈设计，本质上是用“拷贝”换来了“轻量”。初始 2KB 的栈使得 goroutine 可以大量存在，而按需扩容机制让调用深度不受固定栈大小限制，栈收缩又避免了内存浪费。理解这套机制后，你就不会再把 goroutine 当作“随便创建”的对象，而是会像考虑数据库连接一样，认真评估每个 goroutine 可能占用的资源。
原创文章，作者：fudengji，如若转载，请注明出处：https://fudengji.cn/article/537/
