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

把一个 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 的线程在内核里阻塞。

go work() 背后发生什么

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

可运行的 G 不只放在一个队列里。分层队列让大多数操作在 P 本地完成，减少所有 P 争抢同一把全局锁；同时保留全局队列处理溢出和跨 P 工作。

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

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

schedule → findRunnable → execute

schedule 是一轮调度的主入口；findRunnable 负责寻找一个可以运行的 G；execute 把 G 切到运行态并真正恢复它。当前查找逻辑很复杂，下面是便于理解的主干，不应背成一条永远固定的严格顺序：

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

任务窃取（work stealing）是空闲 P 从繁忙 P 的本地队列拿走一部分 G 的负载均衡方法。当前实现通常尝试拿走对方队列约一半任务，而不是每次只拿一个。

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

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

阻塞表示当前任务暂时无法继续，例如在等 Channel 数据、等互斥锁、等网络响应或等操作系统完成调用。关键问题不是“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 使用完成端口。它负责等待“这个连接现在可以读或写了”，避免一条网络连接长期占住一条 M。

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

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

G 进入系统调用后与当前 M 一起进入内核。为了不让其他可运行 G 饿死，运行时会让 P 脱离阻塞的 M，并寻找或创建另一条 M 来接手 P。sysmon 也会回收长时间停在系统调用上的 P。

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

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

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

同步安全点与异步安全点

安全点（safe point）是运行时能够可靠暂停 G，并正确识别栈和寄存器中指针的位置。

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

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

Go 1.25 的容器默认值变化

Go 1.24 及之前，默认值主要是机器可见的逻辑 CPU 数。Go 1.25 起，如果程序没有手工设置，Linux 上的运行时会综合逻辑 CPU、CPU 亲和性和容器 cgroup CPU 限额选择默认值，并周期性检查资源变化。cgroup 是 Linux 用来限制和统计一组进程资源的内核机制，这里负责表达容器可用的 CPU 配额。

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

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

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

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

第一个实验用原子计数记录“同时进入计算区的 goroutine 数”。原子操作（atomic operation）是不会被其他并发操作看到一半状态的单步读改写，这里只用它安全统计数量。

package main

import (
    "fmt"
    "runtime"
    "sync"
    "sync/atomic"
)

func main() {
    runtime.GOMAXPROCS(2)
    var running, peak atomic.Int32
    var wg sync.WaitGroup

    for i := 0; i < 8; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            n := running.Add(1)
            for {
                old := peak.Load()
                if n <= old || peak.CompareAndSwap(old, n) { break }
            }
            for x := 0; x < 30_000_000; x++ {}
            running.Add(-1)
        }()
    }
    wg.Wait()
    fmt.Println("观测到的峰值：", peak.Load())
}

把值从 1 改成 2 或 4，多次运行比较。这个实验只能近似观察业务代码进入计算区的重叠程度，操作系统、编译优化和采样时机都会影响结果，不能把某一次输出当作调度规范。

go test -run TestWork -trace trace.out ./...
go tool trace trace.out

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

go tool trace 是 Go 自带的执行追踪查看器，可观察 G 的运行、阻塞、系统调用、网络等待和垃圾回收时间线；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 不是业务代码要直接调用的框架，它的价值是帮助你判断并发上限、阻塞类型、性能工具和故障原因。下面只保留最常见的落地场景。