为什么 Go 的 goroutine 创建成本这么低：从栈初始化到调度开销的全链路分析

线程为什么“重”：一次创建要动内核

先看最直观的对比对象：线程。在 Linux 上创建一个线程，背后是 clone 系统调用。内核需要新分配线程描述符，设置独立的内核栈，考虑虚拟内存映射，哪怕线程之间共享进程地址空间，页表相关的工作也省不掉。默认的线程栈通常有 8MB 虚拟内存，虽然物理内存按需分配，但地址空间的建立和栈区域的保护设置已经足够让创建操作慢一个数量级。

为什么 Go 的 goroutine 创建成本这么低：从栈初始化到调度开销的全链路分析

线程一旦多起来，上下文切换的成本也避不开。每次切换都要陷入内核，保存和恢复寄存器、切换页表、走调度算法。这也就是为什么线程池是后端开发里绕不开的基础设施，创建线程的成本太高，必须靠复用摊薄。

栈初始化：2KB 的初始栈与按需增长

goroutine 的第一个优势在栈。Go 给每个 goroutine 准备的不是 8MB，而是一块非常小的初始栈，通常在 2KB 左右。大多数 goroutine 的生命周期里，函数调用深度和局部变量都不会超过这个量，所以很多 goroutine 从头到尾就用原来那 2KB。

一旦某个 goroutine 递归很深，运行时会在触发扩容时分配更大的栈，并把旧内容移动过去。这种动态栈设计让“小栈”成为常态，而不是例外。更要紧的是，goroutine 的栈分配不再走 mmap 这类系统调用，而是从 Go 运行时自己管理的内存池里拿，分配速度快了一个量级。

创建过程：对象复用加一次入队

再看创建路径。goroutine 的入口在运行时层面对应的是 newproc，简化后的逻辑差不多是这样：

func newproc(fn):
    g := getFromFreeList()    // 复用已退出的 goroutine
    if g == nil:
        g = allocGoroutine()  // 分配 g 结构体
        g.stack = allocStack(2KB)
    g.dispatch = fn
    g.status = runnable
    runqput(currentP, g)      // 放入当前 P 的本地队列

整条路径没有系统调用，也不涉及内核对象。真正的工作只有两件：分配或复用 g 对象，以及把它塞进队列。其中复用机制很重要，服务里频繁创建和销毁 goroutine 时，新 goroutine 可以直接从空闲列表拿到之前的对象，进一步降低成本。

这里容易产生一个误解：好像创建一个 goroutine 就是分配一个结构体，所以成本可以忽略。其实分配结构体本身也不是免费的，只是相比线程创建已经接近零头。真正有意思的是，连这步都可以通过复用缓存掉一部分。

调度开销：GMP 把创建与线程解耦

再说调度。Go 的 GMP 模型里，G 是 goroutine，M 是系统线程，P 持有本地运行队列并负责调度 G。创建 goroutine 只是把 G 加入某个 P 的队列，并不会立即创建一个 M。只有当现有 M 都在阻塞状态，队列中还有 G 等待执行时，调度器才会考虑增加 M。所以在最常见的创建场景中，goroutine 创建不需要等待内核返回一个线程句柄，调度开销自然被压到最低。

goroutine 的切换也发生在用户态。调度器只需要保存和恢复 G 的执行上下文，不需要陷入内核切换页表。这个切换成本当然不是零，但相比线程切换接近两个数量级的差异，也算得上轻量。

下面这张表可以比较直观看到两者的关键差异。

对比项	线程	goroutine
初始栈大小	默认约 8MB 虚拟内存	通常 2KB 起步
创建路径	clone 系统调用	用户态分配对象并入队
调度模型	内核调度器	Go 运行时 GMP 模型
上下文切换	内核态切换，页表切换	用户态切换，寄存器保存/恢复
对象复用	依赖线程池	运行时空闲列表复用 G
常规并发规模	数千级需谨慎	数十万级更常见

goroutine 不是免费的午餐

既然创建成本这么低，很容易让人产生“随便建 goroutine 不会有事”的错觉。在一些高并发服务里，这种问题很常见。比如一个请求需要并行调下游多个服务，业务同学顺手在每个请求里创建 3 到 5 个 goroutine。一旦请求量上来，goroutine 数量很容易冲到几十万。虽然每个 goroutine 只占几 KB，内存总量还不是主要矛盾，关键是这些 goroutine 都在等下游超时，它们占据的调度资源让同一进程里的其他请求都开始变慢。

所以需要重新理解“成本低”：创建成本低，不代表调度成本低，更不代表同步成本低。