Go GMP 调度器深度模型：G、M、P 如何协作

先看日常用法：两件互不依赖的事可以同时推进

用户注册后，系统既要生成欢迎资料，又要发送邮件。两件事互不依赖，可以各自放进一条 goroutine。下面的 make 是创建并初始化特定 Go 数据结构的内置函数，chan 是声明 Channel（通道）的关键字；results 是容量为 2 的“完成结果通道”，taskName 是主流程当前收到的任务名称。

results := make(chan string, 2)

go func() {
    generateWelcomeFile()
    results <- "欢迎资料"
}()

go func() {
    sendEmail()
    results <- "邮件"
}()

for i := 0; i < 2; i++ {
    taskName := <-results
    fmt.Println(taskName, "完成")
}

Channel（通道）是 goroutine 之间传递数据或完成信号的工具。两行输出的先后不保证，但两个任务最终都会完成；这正说明代码描述的是“可以同时推进”，不是规定固定执行顺序。

没有运行时调度会怎样

如果每创建一条 goroutine 就永久创建一条操作系统线程，十万个并发任务会带来大量线程内存、创建销毁和上下文切换成本。上下文切换是处理器暂停当前线程、保存现场，再恢复另一条线程的过程。

再用厨房建立三个角色的画面

把一个 Go 程序想成餐厅厨房。客人可能瞬间提交几千张订单，但厨房不会为每张订单永久雇一个厨师，而是让有限的厨师和工位不断切换订单。

并发不等于并行

并发（concurrency）是多个任务在同一时间段内交替推进；并行（parallelism）是多个任务在同一时刻真的一起执行。一个 P 也能并发处理很多 G，但同一时刻只能执行一个普通 Go 任务；多个 P 才可能让多个 G 并行。

G：goroutine 的运行档案

goroutine 是由 Go 运行时管理的轻量并发任务，代码里用 go f() 创建。运行时用内部的 g 结构记录它的栈范围、状态、下一条要执行的指令位置、当前关联的 M、阻塞原因等信息。

栈（stack）是函数调用时保存局部变量、参数和返回位置的内存区域。goroutine 的栈可以按需增长，所以创建大量 G 通常比创建同等数量的操作系统线程轻得多。

M：承载执行的操作系统线程

M 对应运行时的 m 结构，背后通常是一条操作系统线程。M 保存当前执行的 G、持有的 P，以及用于调度的 g0。g0 是每个 M 自带的系统 goroutine，专门在系统栈上执行调度、栈管理等运行时代码，不承载普通业务函数。

P：执行权与每处理器资源

P 对应运行时的 p 结构。它不是真实 CPU，也不是一条线程；它保存本地可运行队列、内存分配缓存、计时器（记录未来何时唤醒任务的运行时对象）等“执行 Go 代码需要且适合按并行单元拆分”的资源。P 的数量等于当前 GOMAXPROCS。

运行时给 G 维护状态。理解状态比死记函数名更重要，因为调度本质就是“让 G 在不同状态之间安全转换”。下面只列面试最常用的主状态；源码中还有扫描标记等组合状态。

_Gsyscall 是另一条重要分支，表示 G 正在进行系统调用。系统调用（system call）是程序请求操作系统执行文件读写、线程休眠等内核能力的入口；内核是操作系统直接管理处理器、内存和设备的核心部分，系统调用可能让承载 G 的线程在内核里阻塞。图中的 Channel 是 goroutine 之间传递数据和同步状态的通道。

go work() 背后发生什么

编译器是把 Go 源代码转换成机器可执行程序的工具；空闲 G 池是运行时保存已结束、可重新利用的 G 对象的地方。沿着下面五步，可以看到一条新任务怎样从代码进入可运行位置。

1. 编译器把 go work() 转换为对运行时 newproc 的调用。
2. newproc1 优先从 P 的空闲 G 池复用对象；没有可用对象时再分配 G 和初始栈。
3. 设置函数入口、参数、父 G 等信息，把新 G 标成 _Grunnable。
4. runqput 通常把新 G 放进当前 P 的 runnext（优先运行槽），或放进这个 P 自己维护的本地可运行队列。
5. wakep 在有空闲 P 且需要更多执行者时尝试唤醒 M。

可运行的 G 不只放在一个队列里。分层队列让大多数操作在 P 本地完成，减少所有 P 争抢同一把全局锁；全局锁是保证同一时刻只有一个执行者修改共享队列的互斥机制。运行时同时保留全局队列处理溢出和跨 P 工作。

本地队列满了为什么不是只挪一个

当前 runqputslow 会把本地队列中约一半任务连同新 G 批量放进全局队列。批量移动能减少频繁获取全局调度锁，也给其他 P 获得工作的机会。

schedule → findRunnable → execute

schedule 是一轮调度的主入口；findRunnable 负责寻找一个可以运行的 G；execute 把 G 切到运行态并真正恢复它。查找前还可能处理“停止世界”（stop the world，简称 STW，暂时停下业务 G 以完成全局协调）和垃圾回收（garbage collection，简称 GC，自动找出并回收不再使用的内存）等特殊工作。当前查找逻辑很复杂，下面是便于理解的主干，不应背成一条永远固定的严格顺序：

1. 先处理 STW 协调、执行追踪和 GC 工作者等运行时特殊任务。
2. 为了公平，每隔一定调度轮次检查全局队列；schedtick 是 P 已完成调度的轮次计数，Go 1.26.0 源码使用 schedtick % 61 == 0 判断这条检查路径。
3. 优先从当前 P 的 runnext 和本地队列取 G。
4. 检查全局队列、网络轮询结果和已经到期的计时器。
5. 随机选择其他 P，尝试窃取可运行 G 和计时器工作。
6. 确实没有工作时释放 P，让 M 自旋、休眠或阻塞等待网络事件。

下面固定一个例子走完整条线：P2 的 schedtick=62，所以 62 % 61 = 1，不满足公平检查条件；本地队列和全局队列也都为空，但网络轮询器刚返回 G9。蓝线是本例实际走的路径，绿色框是可能命中的出口，虚线是本例没有进入的出口。

任务窃取（work stealing）是空闲 P 从繁忙 P 的本地队列拿走一部分 G 的负载均衡方法。当前实现通常尝试拿走对方队列约一半任务，而不是每次只拿一个。图中的原子比较并交换表示一次不可被其他线程看到中间状态的“先确认旧值、再写入新值”操作，用来避免两个 P 重复拿走同一条 G。

为什么还要有“自旋”的 M

自旋（spinning）是 M 暂时不休眠，主动寻找工作。新 G 可能马上出现，如果所有空闲 M 都立刻睡死，频繁唤醒线程会增加延迟；但自旋 M 太多又会白白消耗 CPU，所以运行时保守控制自旋线程数量，并遵守“有工作时唤醒、没工作时逐步停下”的策略。

阻塞表示当前任务暂时无法继续，例如在等 Channel 数据、等互斥锁、等网络响应或等操作系统完成调用。I/O 来自 Input/Output（输入/输出），这里主要指网络或文件读写。文件描述符是操作系统分配给已打开连接或文件的整数编号；cgo 是 Go 调用 C 语言代码的桥接机制。关键问题不是“G 是否阻塞”，而是“承载它的 M 是否也必须一起阻塞”。

1. Channel 或锁等待：只停 G

当 Channel 没有可接收数据，运行时会把等待信息挂入队列，再通过 gopark 把当前 G 从运行状态切走。M 切到自己的 g0 执行调度，仍然拿着 P 去运行另一个 G。条件满足时，goready 把原 G 改回可运行状态并放回队列。

G1 在 M1 + P1 上执行
  ↓ 等 Channel
gopark(G1) → G1: waiting
  ↓
M1 + P1 转去执行 G2
  ↓ 发送方送来数据
goready(G1) → G1: runnable → 某次再次运行

2. 网络 I/O：把“等网卡”交给网络轮询器

网络轮询器（netpoller）是运行时对操作系统 I/O 事件机制的统一封装；Linux 常用 epoll，macOS 与 BSD 系统常用 kqueue，两者都是让一个线程同时等待许多连接状态变化的事件接口；Windows 使用作用相近的 I/O 完成端口。它负责等待“这个连接现在可以读或写了”，避免一条网络连接长期占住一条 M。

1. G 发起网络读写，当前没有数据可处理。
2. 运行时登记关注的读写事件，并把 G 停在 I/O 等待状态。
3. M + P 继续执行其他 G。
4. 操作系统报告文件描述符已就绪，网络轮询器取回对应 G。
5. G 被标为可运行，回到调度队列等待执行。

3. 阻塞系统调用：M 可以等，P 必须尽量继续工作

G 进入系统调用后与当前 M 一起进入内核，P 先进入“系统调用中”的状态。如果调用很快返回，M 可能继续拿回原 P；如果等待持续、同时还有其他可运行 G，sysmon 或其他调度路径可以接管这个 P，再寻找或创建另一条 M 执行工作。

M1 返回用户态时会先尝试拿回原 P，再尝试空闲 P。拿不到时，G1 变回可运行并进入全局队列，M1 则停下等待；它不能绕过 P 直接执行普通 Go 代码。

sysmon 来自 system monitor，是运行时的系统监控线程。它不需要 P 就能运行，会监控长时间执行的 G、停在系统调用中的 P、网络事件和计时器等。抢占（preemption）是调度器要求正在运行的 G 暂停，把执行机会让给其他任务。

当前源码用约 10 毫秒的 forcePreemptNS 作为检测长时间占用的实现阈值。它不是承诺“每个 G 精确运行 10 毫秒”，因为检测、信号送达、安全点和操作系统调度都会带来偏差。

同步安全点与异步安全点

安全点（safe point）是运行时能够可靠暂停 G，并正确识别栈和寄存器中指针的位置；寄存器是 CPU 当前保存少量计算数据和指令状态的高速存储位置。

asyncPreempt 保存寄存器后进入调度逻辑，原 G 从运行态回到可运行队列，以后从暂停位置继续。这改善了没有函数调用的长循环长期霸占 P 的问题。

GOMAXPROCS 的名字来自“Go maximum processors”，它告诉运行时允许多少个 P，也就是最多允许多少条线程同时执行普通 Go 代码。它不限制 G 的总数，也不限制因系统调用而阻塞的 M 数量。

Go 1.25 的容器默认值变化

语言版本为 Go 1.24 及之前时，默认值主要是进程可见的逻辑 CPU 数。模块在 go.mod 中声明 Go 1.25 或更高版本后，如果程序没有用 GOMAXPROCS 环境变量、runtime.GOMAXPROCS 函数或相关 GODEBUG 开关覆盖默认行为，Linux 运行时会综合逻辑 CPU 数、CPU 亲和性和容器限额选择默认值，并周期性检查变化。CPU 亲和性是操作系统限制进程可以在哪些 CPU 上运行的规则；cgroup 是 Linux 用来限制和统计一组进程资源的内核机制，这里负责表达容器 CPU 配额。

第一次读调度器源码不要从几千行的 proc.go 顶部顺序往下读。按一条 G 的生命周期追调用链，更容易建立完整地图。

最小伪代码：把主循环压缩成十行

func schedule() {
    for {
        gp := findRunnable() // 可能阻塞，直到找到工作
        execute(gp)       // 切到 gp；以后从 g0 回到这里
    }
}

func findRunnable() *g {
    // 伪代码：特殊任务 → 公平检查全局 → 本地 → 全局
    //       → 网络/计时器 → 从其他 P 窃取 → 休眠等待
}

普通计数器无法证明“同一时刻有几个 G 真正在执行”：G 被抢占后虽然不占 CPU，函数却还没有结束，计数很容易把“尚未完成”误当成“正在并行”。下面改用 Go 自带的执行追踪记录真实时间线。

package main

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

func cpuWork(seed uint64) uint64 {
    x := seed
    for i := 0; i < 12_000_000; i++ {
        x = x*1_664_525 + 1_013_904_223
    }
    return x
}

func main() {
    runtime.GOMAXPROCS(2)
    f, err := os.Create("trace.out")
    if err != nil { panic(err) }
    if err := trace.Start(f); err != nil { panic(err) }

    var wg sync.WaitGroup
    results := make(chan uint64, 8)

    for i := 0; i < 8; i++ {
        wg.Add(1)
        go func(id int) {
            defer wg.Done()
            results <- cpuWork(uint64(id + 1))
        }(i)
    }
    wg.Wait()
    close(results)
    var checksum uint64 // 合并结果，保证计算结果确实被使用
    for result := range results { checksum ^= result }

    trace.Stop()
    f.Close()
    fmt.Println("计算校验值：", checksum)
}

执行追踪（execution trace）是运行时记录 G 何时运行、等待和被唤醒的时间线。代码中的 checksum 是把八次计算结果合并成一个校验值，确保这批计算的结果真的被程序使用。先用 GOMAXPROCS=1 运行，再改成 2；在追踪页面的处理器时间线中，可以直接观察同一时刻运行普通 Go 代码的数量，而不是用函数开始和结束之间的计数猜测并行度。操作系统负载会影响总耗时，但不会改变 GOMAXPROCS 的并行度上限语义。

go run main.go
go tool trace trace.out

# 每 1000ms 打印一次调度器摘要
GODEBUG=schedtrace=1000,scheddetail=1 go run main.go

go tool trace 是 Go 自带的执行追踪查看器；GODEBUG 是控制运行时诊断行为的环境变量，schedtrace 会把 P、M、运行队列等摘要打印到标准错误输出。

1. 角色：G 是 goroutine，M 是操作系统线程，P 是执行权和本地调度资源。
2. 并行度：P 数量等于 GOMAXPROCS，限制同时执行普通 Go 代码的线程数。
3. 队列：每个 P 有 runnext 和本地队列，另有共享全局队列；本地队列当前是 256 槽。
4. 找工作：兼顾本地、全局、网络、计时器和其他 P；空闲 P 会做 work stealing。
5. 普通等待：Channel、锁等通常只 park G，M + P 继续运行其他 G。
6. 网络等待：可轮询连接交给 netpoller，事件就绪后再把 G 变回 runnable。
7. 系统调用：M 可能阻塞，但 P 可脱离并交给另一条 M；返回的 G 重新申请 P。
8. 公平性：sysmon 监控长时间运行的 G 和 syscall 中的 P，现代 Go 还支持异步抢占。

GMP 不是业务代码要直接调用的框架，它的价值是帮助你判断并发上限、阻塞类型、性能工具和故障原因。下面只保留最常见的落地场景。