Go goroutine 与调度器

1. goroutine 是由 Go 运行时管理的轻量任务#

启动 goroutine 的语法很简单：

1
go fn()

这行代码不会创建一个“用户可直接管理的线程”，而是把 fn 包装成一个由 Go runtime 调度的任务。它有自己的栈、执行状态和调度信息，但并不和操作系统线程一一绑定。

goroutine 轻的原因主要有三个：

• 初始栈很小，并且可以按需增长。
• 调度主要由 Go runtime 完成，不需要每次都直接交给操作系统线程调度。
• 阻塞在 channel、锁、网络 I/O 等位置时，runtime 可以让当前线程去跑别的 goroutine。

所以 Go 能轻松创建成千上万个 goroutine，但这不等于 goroutine 没有成本。每个 goroutine 仍然需要栈、调度状态和 GC 扫描成本。

2. G-M-P 模型：任务、线程、调度上下文分离#

Go 运行时调度器常用 G-M-P 模型解释：

• G：goroutine，本质是待执行任务。
• M：machine，对应操作系统线程，真正被 CPU 调度。
• P：processor，Go 代码执行所需的调度上下文，持有本地运行队列。

M 必须拿到 P 才能执行 Go 代码。GOMAXPROCS 控制的是 P 的数量，也就是同一时刻最多有多少个 goroutine 并行执行 Go 代码；它不是 goroutine 总数，也不是线程总数。

【并发编程 - G-M-P 调度拓扑与阻塞流转】

调度器大致按这个方向工作：

• 每个 P 有本地运行队列，优先执行本地队列里的 G。
• 本地队列没有任务时，会尝试从全局队列取任务。
• 如果全局队列也没有任务，会从其他 P 的本地队列窃取一部分任务，这就是 work stealing。
• 这样可以减少全局锁竞争，同时避免某个 P 很忙、另一个 P 空闲。

3. 阻塞时要分清是 G 阻塞，还是 M 阻塞#

理解 goroutine 调度时，最容易混淆的是“谁被阻塞了”。

如果 goroutine 阻塞在 channel 收发、Mutex.Lock、WaitGroup.Wait 这类 runtime 能识别的同步点上，通常是当前 G 被挂起。M 和 P 可以继续执行别的 G。

如果 goroutine 发起可能长期阻塞的系统调用，阻塞的可能是 M。这时 runtime 会尽量把 P 从当前 M 手里拿走，交给其他可用 M 继续执行 Go 代码。

网络 I/O 又是另一类常见场景。标准库网络 I/O 通常会结合 netpoller，让 goroutine 等待事件通知，而不是让线程一直卡在阻塞 I/O 上。

因此，下面这句话更准确：

goroutine 阻塞不一定等于线程阻塞；线程阻塞也不一定让整个 Go 程序停住。

4. 抢占：长时间运行的 goroutine 也需要被让出#

早期 Go 调度更依赖函数调用、channel 操作、系统调用等位置作为调度点。如果一个 goroutine 长时间运行纯计算循环，可能导致其他 goroutine 难以及时运行。

Go 1.14 起引入异步抢占，Go 1.22+ 中这是默认能力。它改善了长时间运行 goroutine 的调度公平性，但不能把坏代码变成好代码。

下面这种循环仍然不值得鼓励：

1
for {
2
  // 没有退出条件，也没有任何阻塞点
3
}

即使 runtime 能抢占它，它仍会持续消耗 CPU。正确做法通常是提供退出条件，或者在需要等待时使用 channel、context.Context、timer 等机制。

5. goroutine 生命周期必须有人负责#

goroutine 最大的优点是启动容易，最大的问题也是启动太容易。只要 goroutine 没有退出条件，它就会一直占用资源。

常见泄漏来源：

• 接收方一直等 channel，但发送方已经不会再发送。
• 发送方一直往 channel 发，但接收方提前退出。
• 后台 goroutine 没有监听取消信号。
• 循环里反复启动 goroutine，却没有限制并发数量。

判断 goroutine 是否安全，重点不是“能不能启动”，而是：

• 谁负责通知它退出。
• 它阻塞时还能不能被唤醒。
• 上游失败或请求取消时，它是否会一起停止。

1. 主 goroutine 退出后，其他 goroutine 也没机会继续跑#

错误写法：

1
func main() {
2
  go func() {
3
    fmt.Println("background task")
4
  }()
5
}

main 返回后进程结束，后台 goroutine 不会因为“还没执行完”就自动保活。需要等待结果时，应使用 WaitGroup、channel 或其他同步方式。

2. 循环里启动 goroutine，但没有并发上限#

1
for _, item := range items {
2
  go handle(item)
3
}

如果 items 很大，这会瞬间创建大量 goroutine。更稳妥的方式通常是 worker pool、带缓冲 channel 控制并发，或者使用上层任务编排。

3. 以为 Go 1.22 以后所有闭包捕获问题都消失了#

Go 1.22 修复的是常见 for/range 迭代变量声明场景：每次迭代会创建新变量。但如果你复用的是外部变量，仍然可能踩坑。

1
var v int
2
for _, v = range []int{1, 2, 3} {
3
  go func() {
4
    fmt.Println(v) // 仍然是同一个外部变量
5
  }()
6
}

版本说明：Go 1.22 的循环变量语义改动见官方 Go 1.22 Release Notes。

4. goroutine 只启动，不设计退出路径#

1
go func() {
2
  for msg := range ch {
3
    handle(msg)
4
  }
5
}()

这段代码能不能退出，完全取决于 ch 是否会被关闭。如果没有明确的关闭者，这个 goroutine 就可能永久等待。

5. 用 time.Sleep 当同步手段#

1
go doSomething()
2
time.Sleep(time.Second)

这只是“猜”后台任务一秒内能跑完。机器慢、调度延迟、任务变复杂时都会出问题。需要等待完成就显式同步，需要超时就显式设置超时。