Go GMP 原理与调度

Go 语言的高并发能力源于其精巧的运行时调度器。理解 GMP 模型是掌握 Go 并发的关键——它解释了为什么你可以轻松创建上万个 goroutine 而不用担心性能问题。本文从调度器的演进历史讲起，逐步拆解 G、M、P 三个核心角色及其协作机制，并通过 11 个实战场景带你直观理解调度全过程。

1. 调度器演进：从单进程到 goroutine

1.1 单进程时代：不需要调度器

早期操作系统只支持单进程——一个程序跑完，下一个才能开始。所有任务串行执行。

两个致命问题：

• 单一执行流：计算机一次只能处理一个任务
• 进程阻塞浪费 CPU：等待 I/O 时 CPU 完全闲置

1.2 多进程 / 多线程时代

操作系统引入多进程并发：进程 A 阻塞时，CPU 立即切换到进程 B。宏观上"同时"运行多个程序。

新问题来了：

• 高内存占用：每个进程虚拟内存 4GB（32 位），每个线程约 4MB
• 调度开销大：进程/线程的创建、切换、销毁成本高，CPU 大量时间花在调度上
• 并发编程复杂：锁、竞争、同步等问题让多线程开发很头疼

1.3 协程（Coroutine）登场

工程师发现：线程分为"内核态线程"和"用户态线程"两层。CPU 只知道内核线程，用户态线程可以更轻量。

三种协程与线程的映射关系：

Go 的 goroutine 就是 M:N 模型的实现——既轻量又能利用多核。

1.4 goroutine 的特点

• 内存极小：一个 goroutine 初始栈仅 2KB，且可动态伸缩
• runtime 调度：由 Go 运行时调度，而非操作系统
• 协作式 + 抢占式：正常情况下协程主动让出 CPU，但 Go 也加入了基于信号的抢占机制（10ms 强制切换）

1.5 被废弃的老调度器

Go 在 2012 年重新设计调度器前，使用的是一个简单的 G-M 模型：

• 全局只有一个 G 队列，所有 M（线程）都从那里取 G（goroutine）
• 所有操作都要加互斥锁保护全局队列

老调度器的三大缺陷：

1. 激烈锁竞争：创建/销毁/调度 G 都需抢锁
2. 局部性差：G 创建新 G 后可能被丢到其他 M 执行，相关 goroutine 被分散
3. 系统调用开销大：线程频繁阻塞/唤醒增加系统负担

2. GMP 模型核心组件

为解决老调度器的问题，Go 引入了 P（Processor），形成 GMP 三元素模型。

2.1 G（Goroutine）

G 是 Go 中的协程，代表一个待执行的任务。每个 G 包含：

• 栈：goroutine 的执行栈（初始 2KB，可增长到 1GB）
• 指令指针：当前执行位置
• 状态：_Gidle、_Grunnable、_Grunning、_Gsyscall、_Gwaiting、_Gdead 等
• 绑定的 M（如果正在运行）

gotype g struct {
    stack       stack     // 执行栈
    sched       gobuf     // 调度上下文（sp, pc, g 等）
    m           *m        // 当前绑定的 M
    // ...
}

2.2 M（Machine / OS Thread）

M 是操作系统线程，是真正执行代码的实体。每个 M 必须绑定一个 P 才能执行 G。

关键特性：

• M 数量默认上限 10000，但受限于操作系统
• M 阻塞时，P 会被转移到其他空闲 M
• 一个 Go 程序至少有一个 M（M0）

2.3 P（Processor）

P 是 GMP 模型的调度核心，代表执行 goroutine 所需的上下文资源。

P 的数量：由 GOMAXPROCS 决定（默认等于 CPU 核心数），程序运行期间不变。

2.4 全局队列（Global Queue）

除了每个 P 的本地队列，还有一个全局 G 队列。它在新调度器中作用被弱化：

• P 本地队列满时，溢出的 G 放入全局队列
• M 从其他 P 偷不到 G 时，从全局队列获取
• 全局队列仍有互斥锁，但访问频率远低于老模型

2.5 三者的协作关系

核心规则：

• P 的数量决定了真正并行的 goroutine 数量上限
• M 必须"持有"一个 P 才能运行 G
• P 与 M 是 1:1 绑定关系（任意时刻）
• M 阻塞时，P 可以被转移到另一个 M

3. 调度器四大设计策略

3.1 线程复用（Work Stealing）

当某个 M 的 P 本地队列为空时，不会销毁线程，而是：

1. 先从全局队列取一批 G
2. 全局队列也空，就"偷"其他 P 本地队列一半的 G

3.2 Hand Off 机制

当 M 正在执行的 G 发生阻塞系统调用（如文件 I/O、网络 I/O）时：

3.3 抢占调度

传统协程是协作式的（主动让出），一个协程不主动让出就会饿死其他协程。Go 在 1.14 引入基于信号的异步抢占：

• 每个 goroutine 最多连续占用 CPU 10ms
• sysmon 监控线程检测到运行超时的 G，发送 SIGURG 信号
• 信号处理中完成抢占

3.4 利用并行

GOMAXPROCS 控制 P 的数量，也就控制了同时运行 goroutine 的 OS 线程数。默认等于 CPU 核数，让程序充分利用多核。

4. go func() 调度全流程

当你写下 go func() { ... }() 时，调度器经历了什么？

M 的调度循环（简化）：

goschedule() {
    for {
        // 1. 每 61 次调度检查一次全局队列
        // 2. 从 P 本地队列取 G
        // 3. 本地空 → 从全局队列取一批
        // 4. 全局空 → 从其他 P 偷一半（work stealing）
        // 5. execute(G) → 运行 G
    }
}

阻塞时的处理：

5. 调度器生命周期

5.1 特殊的 M0 和 G0

5.2 Hello World 调度全过程

以最简单的 fmt.Println("Hello world") 为例：

6. 十一个调度场景实战解析

场景 1：创建新 goroutine

P1 上 M1 正在运行 G1。G1 中执行 go func() 创建 G2。G2 优先加入 P1 的本地队列。

场景 2：goroutine 执行完毕，线程复用

G1 执行完毕（调用 goexit），M1 上切换到 G0（调度 goroutine）。G0 从 P1 本地队列取出 G2，切换到 G2 继续执行。M1 被复用，没有销毁重建。

场景 3-4：本地队列满，负载均衡

G2 一口气创建了 6 个 goroutine（G3~G8）。前 3 个（G3、G4、G5）填满 P1 本地队列。创建 G6 时发现队列已满，将前一半（G3、G4）和新创建的 G6 一起移到全局队列（顺序被打乱）。

场景 5：有空位继续放入

G2 创建 G8 时，P1 有空位，G8 直接加入 P1 本地队列。

场景 6：唤醒空闲 M

G2 运行时可能唤醒一个空闲的 P2-M2 组合。M2 绑定 P2 后进入自旋状态（不断寻找 G 来执行）。

场景 7：从全局队列取 G

自旋的 M2 发现 P2 本地队列为空，从全局队列取 G。取的数量公式为 n = min(len(GQ)/GOMAXPROCS + 1, len(GQ)/2)，至少 1 个，且不会一次取光。

场景 8：Work Stealing

P2 执行完本地所有 G，全局队列也空了。M2 执行 work stealing——从 P1 的本地队列尾部"偷"一半 G。

场景 9：自旋线程

M3 和 M4 没有 G 可执行，进入自旋状态。自旋线程不执行 G 但占用 CPU——为什么？

场景 10：Hand Off（阻塞系统调用）

M2 上的 G8 发生阻塞 syscall（如读文件），且 G8 创建了 G9：

场景 11：非阻塞网络 I/O

G8 发起网络 I/O（非阻塞），G8 被放入 netpoller 中等待。G8 创建的 G9 留在 P2 本地队列继续执行。M2 不会阻塞，P2 也不需要换 M。

7. 可视化 GMP

7.1 GODEBUG 环境变量

最简单的 GMP 观察方式——运行时打印调度器状态：

gopackage main

import (
    "fmt"
    "time"
)

func main() {
    for i := 0; i < 5; i++ {
        time.Sleep(time.Second)
        fmt.Println("Hello World")
    }
}

bash$ go build -o trace2 trace2.go
$ GODEBUG=schedtrace=1000 ./trace2

输出解读：

7.2 go tool trace

更强大的可视化工具，能在浏览器中查看 G、M、P 的调度关系图：

gopackage main

import (
    "os"
    "fmt"
    "runtime/trace"
)

func main() {
    f, _ := os.Create("trace.out")
    defer f.Close()

    trace.Start(f)
    defer trace.Stop()

    fmt.Println("Hello World")
}

bash$ go run trace.go
$ go tool trace trace.out
# 浏览器打开 http://127.0.0.1:xxxxx → 点击 "view trace"

trace 页面按时间轴展示每个 G、M、P 的状态变化，可以直观看到 goroutine 的创建、切换、阻塞和唤醒全过程。

8. 总结

GMP 模型的精髓可以用一句话概括：

核心要点速查：

理解 GMP，你对 Go 并发的理解就从"会用 goroutine"上升到"理解 goroutine 怎么跑"——这是写出高性能 Go 程序的基础。