CloudCruiser从一次线上事故说起。那段时间服务白天一直很稳，一到晚高峰就开始毛，CPU没上去多少，但接口延迟一直在抖。我看 goroutine 数量曲线，好家伙，每秒钟涨几千个，等告警拉起来的时候已经是几百万的量级。当时第一反应是“是不是连接池没复用”，查来查去都不是，最后用 pprof 抓到堆栈才发现，阻塞全卡在一个 channel 上，而 channel 的接收方因为调度问题根本没机会跑起来。也是从那次之后，我才真正下定决心把 Go 语言调度器 GPM 模型从头到脚啃了一遍。这篇文章就当作一次系统性的复盘，把我对 G、P、M 三个角色、调度循环、work stealing、抢占机制的理解，以及平时排障会用到的观测手段，一起整理出来。如果你也写过 go func() 但没搞懂它背后怎么被调度，或者遇到过 goroutine 泄漏、死循环饿死其他任务这类问题，这篇文章应该对你有用。
用户：P 可以抢占 G 吗？M 能不能换绑？G 进入阻塞之前发生了什么？带着这些问题来读，理解会深很多。
1. GPM 模型到底是什么
1.1 从“三个人物”看调度单元
GPM 是 Go 运行时调度器的三个核心角色缩写：G（Goroutine）、P（Processor）、M（Machine）。很多资料会把 P 翻译成“处理器”，但这个翻译容易误导，它其实不是 CPU，更准确地说，P 是“执行所需上下文”的抽象，是调度器维持的可运行队列和资源集合。M 才是操作系统线程的直接封装，真正在 CPU 上执行代码的是 M。而 G，就是被调度的最小单位，我们写的每个 go 函数都会被包装成一个 G。
我常用的一个类比是这样：把整个 Go 进程想象成一个餐厅，G 是一张张顾客的点菜单，M 是后厨的厨师，每个厨师必须在自己对应的灶台（P）上才能炒菜。P 决定了后厨能同时开工几口锅，也就是并行的极限。菜能不能尽快上桌，取决于菜单怎么排队、厨师之间怎么互相帮工——这就是调度的活。
G 本身很轻量，初始栈大小只有 2KB～8KB（不同版本有差异），而且栈可以动态扩展，一个 G 的结构体在经过各种优化后，也只有一百多字节到几百字节不等。对比操作系统线程动辄 MB 级别的栈空间，goroutine 才能支撑起大规模并发。但轻量不代表没有代价，轻量调度让“任务切换”这件事变得极其频繁，调度器自身的设计直接决定了并发性能和延迟表现。
1.2 M、P、G 各自的底层结构
源码里这三个结构体都在 runtime/runtime2.go 里。G 结构体里最重要的字段是 stack（栈信息）、sched（保存上下文现场，包括 PC、SP 等寄存器值）、atomicstatus（当前状态），以及 goid。切换 G 的时候其实就是保存和恢复一组寄存器现场，同时调整栈指针，所以它的切换开销远小于线程切换。M 结构体里最重要的两个字段是 curg（当前正在执行的 G）和 g0。每个 M 都会有一个特殊的 g0，它不是给用户代码用的，而是负责调度循环和垃圾回收等系统级任务的高优先级上下文。所有 M 开始执行调度循环之前，都会先切到 g0 的栈上，再从 g0 跳转到某个 G 的现场执行。
P 结构体的核心字段是 status 和 runq。status 决定 P 当前处于哪种状态：_Pidle 空闲、_Prunning 被 M 绑定额正在执行、_Psyscall 当前绑定的 M 在做系统调用、_Pgcstop 是 GC 停世界时所有 P 被冻结的状态、_Pdead 是销毁状态。runq 是一个容量为 256 的循环队列，也就是本地运行队列。P 同时还有一个特殊的字段叫 runnext，它只保存一个 G，优先级比 runq 里的所有 G 都高。
关于三者关系，我记得最牢的一句话是：G 必须绑定在某个 P 上才可能被调度执行，但 M 可以没有 P；没有 P 的 M 会进入休眠或自旋状态，不会去执行任何 G。调度器的目标就是尽量让每个 P 都被 M 占住，每个 M 的手里都有活干，不让任何一台“灶台”空转。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 为什么老 GM 模型必须改：历史包袱与新解法
2.1 旧模型的问题集中在“一把锁”
在 Go 1.0 刚发布的时候，调度器模型比现在简单：只有 G 和 M，全局只有一个运行队列，加上一个大的 mutex 保护。当时这么做不是没道理，代码简单、容易保证正确性。但缺点也很致命：每当一个 goroutine 被创建、唤醒或者阻塞，线程都要去抢那一把全局锁；在单核时代这没问题，到了多核环境下，全局锁就成了最大热点，调度本身比执行任务还贵。
另外一个隐藏问题是缓存亲和性差。全局队列是 FIFO 出队的，goroutine A 第一次被某个 M 执行后进入阻塞，下一次醒来可能被任意一个 M 取走。如果它上一次执行的 M 在核 1 上，这次却去了核 2，那么它之前在核 1 缓存中的数据全部失效，需要重新加载。对于内存密集型任务，这种反复迁移会带来很高的成本。可以类比你在工位上把一摞资料整理到一半，突然被人换到隔壁工位，所有资料都得重新摊开一遍。
还要提一个线程数失控的问题。每当一个 G 由于系统调用阻塞了 M，原来的调度器可能会直接创建一个新的 M 去执行其他任务。如果大量 G 同时进入系统调用，就会创建大量线程。线程创建、上下文切换、内存占用都是真实开销，系统负载很容易被拖垮。
2.2 GPM 的新设计怎么解决
GPM 模型的本质是增加了 P 这一中间层，把“并发执行权”和“真实线程”解耦。P 相当于一个本地任务池，数量由 GOMAXPROCS 控制，而 M 的总量可以和 P 不一致。线程多了或少了，不会直接改变可并行任务数量，P 数量才是并行度的边界。
每个 P 都有本地队列，新创建的 G 会优先进入当前 P 的 runnext 或本地 runq，这保证了“刚执行完的 G 后面新创建的 G”大概率还在同一个 P 上继续被调度执行，空间局部性比老的全局队列好很多。全局队列仍然存在，但它降级成溢出缓冲区和跨 P 负载均衡的补充手段。只有本地队列满了、或者让出 P 但找不到空闲 P 时，G 才会被放到全局队列。
GPM 还从底层上支持了两种负载均衡机制：work stealing 和 hand off。前者在 P 本地没任务时去别人那“偷”任务；后者在 M 因系统调用阻塞时把 P 亲手交给另一个空闲 M，避免 P 空转。从这开始，调度器的复杂度提升了一个量级，但也彻底把全局锁剥离出了高频路径。日常开发中，每个 go 语句背后不再需要抢那把全局大锁，大多数情况下只需要往本地队列里放一个对象，用局部无锁或轻量锁就能完成。
3. 一条 goroutine 的完整一生：从 go func() 到调度循环
3.1 创建与入队：为什么新 G 总想插队
当你写下 go func()，编译器会把它翻译成 runtime.newproc 调用。newproc 第一件事是申请一个 G 对象，然后把函数入口地址、参数拷贝到 G 的栈上，设置好 sched.pc 等上下文现场。接下来它不会马上去找空闲 M 执行，而是把 G 放入某个 P 的队列。到底放哪个 P？答案是“当前正在执行这段代码的 goroutine 所在的 P”。这很重要，因为子 goroutine 通常和父 goroutine 有数据关联，放在同一个 P 上可以提高缓存命中率。
放入队列时有个容易被忽略的细节：新 G 并不是直接进入 runq 末尾，而是先放到 runnext。如果 runnext 里本来已经有一个 G，那个 G 会被挤下来，进入 runq 的尾部，新来的抢占它前面的位置。为什么要搞这个插队机制？因为新建 G 的操作方是当前正在运行的 G，它的下一步往往紧接着就要等待新 G 的结果（比如用 channel 传递数据）。让新 G 尽快运行，可以让父子 goroutine 之间的协作延迟降到最低，同时它刚创建的栈和参数也还热乎。
如果本地 runq 也满了（超过 256），runnext 和 runq 中的部分 G 会被批量转移到全局队列。全局队列需要锁保护，所以这条路径上确实会有竞争，但属于“低频兜底”，不像老模型那样所有 goroutine 入队都走这一条路。
3.2 调度循环的“死循环”：schedule → execute → gogo → goexit0
M 一旦绑定到一个 P 上，就进入一个我称之为“永不结束的循环”的逻辑。schedule() 函数会试着找到一个可以运行的 G，找到后调用 execute() 设置好 G 的状态和现场，然后通过汇编指令 gogo 跳转到 G 的代码栈上。用户代码开始执行。当 G 因为某种原因让出处理器时，不管是因为 channel 阻塞、系统调用、主动调用 runtime.Gosched()，还是运行结束，都会经由 gogo 的逆操作重新跳回 M 的 g0 栈，进入 schedule() 的下一次循环。G 本身并不会主动“睡去”，它只是保存好现场，然后调度器换下一个 G 上场。
一个容易搞混的点是：G 和 M 不是永远绑定的。G 在运行中被阻塞后，它所在的 M 会继续去执行其他 G；等之前那个 G 被唤醒，它被塞回某个 P 的运行队列，下一次调度时可能落在另一个 M 上。所以你在看日志时不要认为每个 goroutine 一定和某个线程有对应关系。真正固定不变的绑定是 M 和 P，只要 M 不阻塞，它会一直占着这个 P 执行队列里的所有任务；而一旦 M 做系统调用阻塞，它才会主动和 P 解绑。
如果 G 是正常函数返回，它的最终归宿是调用 goexit0。这一步会做清理：把 G 的状态改成 _Gdead，把栈对象放回空闲缓存池，然后记录一些统计信息，最后把 G 从当前 M 上剥离，重新进入调度循环。那些我们已经不用的 G 不一定立刻销毁，运行时会尽量复用结构体对象，这又是另一个层面的内存优化。
4. P 的本地队列怎么撑起整个调度系统的效率：work stealing 详解
4.1 本地队列为空后，调度器按什么顺序找活干
当一个 M 空闲下来，进入 schedule() 准备找任务时，它不会只盯着本地队列。findRunnable() 是调度循环里最核心的函数，它的查找顺序大概是这样：
- 先看当前 P 的
runnext，如果有 G 就立刻拿出来执行； - 再看本地
runq，从队头取一个 G； - 本地没有，就去全局队列取一批 G（不是只取一个，而是按一定比例批量取），同时为了公平限制全局队列获得执行的机会；
- 全局也没有，就看网络轮询器（netpoll）是否有就绪的 fd 对应的 G；
- 还是没有，就开始从其他 P 那里偷任务；
- 实在偷不到，M 就会进入自旋或休眠状态等唤醒。
这个顺序的设计逻辑很清楚：优先执行当前 P 上的任务，最大程度地保持数据亲和性；然后是全局队列，因为那里是“整个进程里大家都能看到的公共任务”，需要保证它们不会被饿死；最后才是跨 P 偷取，因为跨处理器取任务意味着要把对象从别的 M 的本地缓存中搬过来，损耗最大。
我对全局队列的“批量取”印象很深。源码里从全局队列取 G 的次数不是 1，而是按本地队列长度的一半来取的。这其实是在平衡“给全局公平性”和“减少反复拿锁的开销”两个目标。一次性多取几个，后面几次调度就不用再去抢全局锁了。
4.2 “偷一半”背后的负载均衡智慧
work stealing 并不是把一个任务从别的 P 拿走就算完。在 runqsteal 中，如果对方的 runq 里任务数很多，偷取方会一次拿走大约一半的任务，而不是只拿一个。这个操作同样有讲究：偷一个只能解决当前 P 的一次空闲，但是任务生产的速率可能是不均匀的，过两毫秒这个 P 又没活了，还得再来偷一次，每次都产生跨 P 开销。一次偷一半，等于一次性把未来一小段时间的负载也搬过来了，让两个 P 的队列长度大致均衡，后续再发生 steal 的概率下降很多。
偷取过程也做了防冲突设计。一个 P 不会每次都从固定编号的邻居开始偷，而是会随机选取一个起点，再按固定步长依次尝试其他 P。这样做的好处是避免多个空闲 P 同时去抢同一个繁忙 P 的队列，降低锁竞争和“集群迁移”的震荡。
实际工作里，如果一个服务的请求处理大量使用短生命周期 goroutine，你会发现 work stealing 对延迟稳定性的作用非常明显。假如没有它，假设有 8 个 P，其中 1 个 P 上的 goroutine 持续往它本地塞新任务，而其他 P 已经空转，整个程序就只有 1/8 的 CPU 在干活。work stealing 让空闲 P 能主动找活，保证多核资源被尽量吃满。可以说，它是 GPM 模型里真正意义上的“动态负载均衡器”。
4.3 自旋线程的取舍
M 找不到任务时，不是立刻休眠，而是会先自旋一小段时间（约几十微秒），周期性地检查是否有新任务可偷。自旋的本质是用 CPU 空闲换任务唤醒的延迟，避免线程频繁睡眠、唤醒造成的抖动。如果每次没任务就 sleep，一个短任务到来时需要先唤醒内核线程，这个耗时可能会到几十微秒甚至上百微秒，对高频调度的 Go 程序来说不可接受。
但自旋也有成本，因为它本身占用 CPU。所以运行时对自旋 M 的数量做了限制：最多允许 GOMAXPROCS 个空闲 M 自旋？严格说是根据当前 P 的空闲数和 M 的状态来动态计算，保证不会出现几十个线程都在自旋空烧 CPU 的情况。这个细节在 schedtrace 里能看到：spinningthreads 字段显示当前自旋线程数，生产环境如果这个数字长期很高，说明任务输入波动大或队列负载不均衡，需要关注。
5. 抢占式调度：从“自觉让出”到“信号强杀”
5.1 为什么老版本的死循环能饿死其它 goroutine
GPM 模型里，P 是抢占单位吗？不是，G 的运行可以无比漫长。在 Go 1.14 之前，调度器采取的其实是协作式抢占：运行中的 G 只能在一个安全的点被抢占，所谓安全点，最常见的就是函数调用时的栈检查或栈扩容。调度器会通过后台线程 sysmon 定期扫描，发现某个 G 运行时间过长，会设置一个抢占标记，把它标记为 _Gpreempted。但这个标记要等到该 G 自己触发下一次函数调用、走到栈检查逻辑时才会真正生效。
如果你写了一个纯计算的死循环，而且循环体里没有任何函数调用，抢占标记就永远没有机会被检查。结果就是，这个 G 独占整颗 CPU，其他 goroutine 全部饿死。我印象很深，早期版本跑如下代码：
go复制func main() {
runtime.GOMAXPROCS(1)
go func() {
for {}
}()
time.Sleep(time.Second)
fmt.Println("main done")
}
在 Go 1.13 及之前，这段代码大概率永远也不会打印 main done，因为那个空循环死占着唯一一个 P 不放。这是新手最容易踩到的坑，也是我当时排障时绕了很久的问题来源。
5.2 信号抢占：Go 1.14 带来的能力跃迁
Go 1.14 引入了基于信号的异步抢占。大概原理是：sysmon 线程发现某个 G 运行时间超过阈值（比如 10ms），会向该 G 所在的 M 发送一个 SIGURG 信号。M 的信号处理函数收到信号后，会在一个安全点保存当前 G 的现场，然后让出控制权，交回调度循环。因为这是真正的异步中断，G 即使在一段没有任何函数调用的循环里也能被打断。
为什么选 SIGURG？它相对冷门，不容易和业务里常用的 SIGTERM、SIGINT 等冲突，同时也不会像 SIGQUIT 那样会导致进程退出。运行时会为每个 M 注册专门的信号处理函数，在处理前会校验信号是不是来自自身进程、目标线程是否符合预期，避免误伤。
从这以后，上面的死循环程序可以被正常抢占，其他 goroutine 也能获得执行。更关键的是，垃圾回收的 STW（Stop The World）阶段不再需要等待所有 G 主动走到安全点，而是可以强制中断那些已经运行过久的任务，这是 GC 延迟大幅改善的重要基础。
但是在实际开发中，我依然不建议写那种完全没有函数调用、纯 CPU 转圈的代码。一方面它让信号抢占成为唯一保障，另一方面它本身也容易掩盖程序逻辑里的自旋等待问题。能用 channel 或等待组表达的协作，就别用空循环硬等。
5.3 sysmon：最容易被忽略的幕后角色
sysmon 是一个特殊的后台线程，它不需要绑定 P 就能运行，所以在任何 P 状态恶劣时它都能出手兜底。它的主要工作有几个：清洗被长时间阻塞的 P（比如 M 在系统调用中卡了太久的 P，会被 sysmon 标记并把 P 交给别的 M）；对运行时间过长的 G 发出抢占信号；定期检查 netpoll 是否有 fd 事件需要唤醒 G；还要监测死锁。假如你怀疑程序“卡死”，多想想是不是 sysmon 没有正常运转或者它检测到某种死锁条件。
这个线程存在很多年了，但因为不占 P，又不直接跑用户代码，很多人调优时根本注意不到它。看 GPM 模型如果只看 M/P/G 和三个队列，不看 sysmon，就没法解释为什么阻塞的系统调用能被打断，以及 GC 为什么能做到比较短的 STW。它是调度器里的“监工”，负责在任务执行失控时强行干预。
6. 阻塞、系统调用与 hand off：M 和 P 什么时候“分手”
6.1 channel 阻塞不绑线程，系统调用才会拖住线程
G 在运行中遇到 channel 收/发阻塞，状态会变成 _Gwaiting，但从 M 的角度看，它并没有陷入内核阻塞，P 也不会被释放。调度器会把当前 G 从运行队列中摘除，保存好现场，然后从本地队列里重新拿一个新的 G 继续执行。如果本地队列没有了，就执行刚才那一整套 findRunnable 流程。整个过程完全不涉及线程上下文切换和内核对象等待，这也是为什么 goroutine 并发模型可以在高并发下表现得比线程池更从容。
真正会让 M 脱手的场景是系统调用，比如读写文件、访问网络、调用 CGO、或者加一些会进入内核等待的锁。系统调用意味着 M 对应的线程会被内核挂起，不能继续执行任何 Go 代码。如果此时 P 还绑定在这个 M 上，那么这个 P 的任务就全被冻结了，浪费一个处理器资源。于是运行时会在 G 进入系统调用前后检查：如果这个系统调用可能阻塞（entersyscallblock 或检测到调用过长），M 会把当前 P 解绑，P 转为 _Psyscall 或 _Pidle 状态，然后调度器可以把它交给其他空闲 M。
这个过程叫 hand off。一个 G 在做系统调用，但 P 不会陪它一起等。等系统调用返回后，原来的 M 会先尝试重新绑定一个空闲 P，找到就继续执行当前 G；找不到的话，当前 G 会被放回全局队列，而 M 则进入休眠待命，等待未来某个 P 空闲时再去绑定。
6.2 “同伙换班”的真实代价
hand off 听上去很优雅，但如果系统调用非常多且非常短，频繁的 P 解绑和重新绑定开销会超过任务本身。网络 I/O 相对特殊，Go 运行时通过 netpoll（基于 epoll/kqueue/IOCP）做了非阻塞封装，纯网络读写并不会让 M 陷入阻塞，所以不会触发 hand off。真正会造成 M 阻塞的通常是本地文件读写、CGO 调用、操作数据库驱动的某些同步调用等。
实操中如果遇到“线程数量不断上涨”的问题，先排查是不是某条路径调用了阻塞型系统调用且没有走异步封装，或者 CGO 调用被大量并发执行。每次 M 因阻塞解绑 P，系统偷偷多开一个线程；等阻塞结束后这些线程又不会马上销毁，最终可能积累到几千个线程。线程多不代表好，内核调度负担和内存占用都会拖垮服务。
我一直建议，写 Go 服务时控制并发量的主要手段是 channel + goroutine 这个层次，而不是盲目相信调度器能无限兜底。系统调用密集的场景，用一个协程池限制并发的系统调用数量，往往比提高 GOMAXPROCS 更有效。
7. 从观测到调优：GOMAXPROCS、schedtrace、pprof 与故障排查
7.1 GOMAXPROCS 到底在调什么
GOMAXPROCS 决定 P 的数量上限，也决定了同一时间真正执行用户 Go 代码的线程数量上限。默认情况下，Go 运行时读取的是宿主机的逻辑 CPU 数。这个默认值在裸机环境没问题，但在容器环境要注意：如果容器限制的是 4 核，而宿主有 64 核，旧版 Go 读取到的还是宿主机的核心数，导致 P 开到 64，大量线程在容器里来回切换，性能反而更差。新版 Go 已经有容器感知能力，但如果使用的是较老版本或者遇到 cgroup 复杂场景，建议显式设置：
go复制// 在 main 函数最前面设置
runtime.GOMAXPROCS(4)
更优雅的方式是用社区库 uber-go/automaxprocs，它会在 init 阶段自动读取 cgroup 配额并设置 GOMAXPROCS。如果你的服务部署在 Kubernetes 这类容器平台，我非常建议引入这个库，能省掉很多隐藏的性能抖动。
需要提醒一下：GOMAXPROCS 调大不会自动让单个 goroutine 的执行变快，它只影响可以同时运行的 goroutine 数量。CPU 密集型任务，P 超过实际可用核数会带来线程切换；IO 密集型任务，单纯调大 GOMAXPROCS 不如控制好异步化和并发上限。还有一个心得：某些性能 Benchmark 跑分时，GOMAXPROCS 设置过大，反而会因为 P 之间的 steal 和缓存失效导致分数反而下降。
7.2 GODEBUG 打开黑盒：schedtrace 能告诉我们什么
调试调度器问题，最直接的手段是设置环境变量：
bash复制GODEBUG=schedtrace=1000 ./your_program
这会每 1000ms 输出一行调度摘要，大概长这样：
code复制SCHED 0ms: gomaxprocs=4 idleprocs=0 threads=5 spinningthreads=1 idlethreads=0 runqueue=2 [0 1 0 0]
逐个字段看：gomaxprocs 是当前 P 数量；idleprocs 是空闲 P 数量；threads 是当前 M 总数；spinningthreads 是正在自旋但没有任务的 M 数量；runqueue 是全局运行队列长度；最后一个方括号里的数分别表示每个 P 的本地队列长度。这个输出能直接看出负载是不是均衡：如果某个 P 的本地队列长期很大而其他 P 一直是 0，可能任务分配模式有问题；如果 spinningthreads 长期很高，说明总有 M 在空转，可能是任务产入不够平滑。
想看得更细，可以加 scheddetail=1，输出里会带出每个 P 的状态、每个 M 的绑定情况和更多统计信息，适合深入排查。但需要说明，它会打印大量信息，只建议在测试环境临时开启，生产环境这样打日志会干扰性能。
7.3 排查 goroutine 泄漏的常规路径
goroutine 数量只涨不降，通常是某种阻塞没有解除，卡在 _Gwaiting 状态的 G 越积越多。标准排查流程是：
先通过 pprof 查看 goroutine 堆栈聚合：
bash复制go tool pprof http://localhost:6060/debug/pprof/goroutine
进到 pprof 交互界面后输入 top 可以看哪些调用点创建/阻塞了大量 goroutine，输入 traces 可以看完整堆栈。最能说明问题的是堆栈里的等待位置，比如 chan receive、sync.Mutex.Lock、select 等。看到大量 goroutine 卡在同一个 channel 接收上，基本可以断定发送方缺失或发送频率远低于接收期望。
再用 trace 观察时间轴分布：
go复制import "runtime/trace"
f, _ := os.Create("trace.out")
trace.Start(f)
defer trace.Stop()
打开 go tool trace 后，可以看 goroutine 的状态分析以及网络/系统调用等待，定位延迟到底消耗在调度、阻塞还是 GC。
我自己的排障习惯是：先看 goroutine 堆栈，再结合 schedtrace 的全局队列长度判断是“任务太多没消化完”还是“任务根本没被唤醒”。前者的特征是队列积压、CPU 打满；后者的特征则是 CPU 不高，但 goroutine 数不断攀升，整体像死水一样。
7.4 常见的“伪调度”坑：不要滥用 Gosched 和自旋锁
runtime.Gosched() 的本意是主动让出当前 P，让其他 G 先跑。但如果频繁调用，它会让调度器反复切换任务，造成上下文切换开销放大，而且时机不可控，容易引发某些 G 一直排队。除非是为了绕开一个非常明确的饥饿场景，否则在业务代码里显式调 Gosched 通常是调度设计出现问题的信号，应该优先用 channel 或锁来协作，而不是手动干预调度。
另一个坑是自旋锁。某些开发者为了图快，用 for { atomic.Load(...) } 实现等待，这在单 G 场景里可能没问题，但如果多个 G 同时在多个 P 上自旋等待同一个变量，它们会烧满 CPU，且因为协作式调度和抢占的介入，可能导致等待方被连续抢占，迟迟等不到持有者更新变量。正确做法是让等待方阻塞在 channel 或 sync.Cond 上，把 CPU 让给真正做事的人。
8. 那些年我踩过的 GPM 相关的坑：典型问题速查
下面这几个问题，是我在给团队做技术分享时整理的真实案例，每一个都对应过一次线上或压测事故。整理成表的时候刻意没写太深，但如果你的症状能对得上号，顺着这个方向排查，命中率很高。
| 现象 | 根因方向 | 排查手段 |
|---|---|---|
| goroutine 数量百万级，CPU 低下 | channel接收方缺失，发送方持续产生，G 全部阻塞在等待上 | goroutine pprof 栈顶出现 chan receive；trace 找出长期等待 |
| CPU 跑不满，单 P 本地队列长期积压 | 有 G 长期占用 P 不释放，或 syscall 阻塞导致 P 被占用 | GODEBUG=schedtrace 观察每个 P 队列长度和 idleprocs |
| 线程数持续上涨，远超核数 | M 因系统调用阻塞然后不断解绑重建，常见于 CGO/磁盘IO | 查 entersyscall 相关堆栈，用 strace 看线程数 |
| 单个 goroutine 死循环导致其他任务卡顿 | 若 Go 1.14 之前，协作式抢占失效；若新版本，要查是否每次循环都发生函数调用 | 升级版本；优化代码结构，避免无函数调用死循环 |
| 容器内服务吞吐明显低于预期 | GOMAXPROCS 默认读到宿主机核数，容器内 P 过多 | 使用 uber-go/automaxprocs 或显式设置 |
| 大量短任务频繁创建，全局队列 QPS 增加 | 单 P 本地队列满，G 溢出到全局队列，全局锁出现竞争 | 优化任务粒度或批量处理，减少跨 P 迁移 |
还有一个容易被忽略的问题是内存。G 的栈可以动态增长，但增长之后不会立即缩回很小。如果某个 goroutine 曾经高峰期使栈扩展到很大，接着进入长时间的阻塞等待，它占用的栈内存就白白挂着。大量这样的 goroutine 会显著拉高内存占用。所以排查“内存高但应该不是泄漏”时，也要看一眼 goroutine 数量以及每个 goroutine 的栈大小，说不准真正的问题是 goroutine 泄漏和栈空间滞留的组合效果。
9. 从源码角度看 GPM 的几条关键链路（带注释伪代码）
前面说了很多概念，为了让大家在面对调度问题时能有代码层面的抓手，我把几条关键路径的伪代码整理出来，方便和实际源码对照。
9.1 创建 goroutine 的入队路径
go复制func newproc(fn *funcval) {
gp := getg() // 获取当前运行 G
pc := getcallerpc()
newg := newproc1(fn, gp, pc) // 创建 G，初始化栈和现场
// 关键：放入当前 P 的 runnext；原 runnext 被挤出
runqput(gp.m.p.ptr(), newg, true)
}
newproc 有一个关键参数是“当前 P”，而不是“空闲 P”，这就保证了子任务尽量和父任务在同一个执行上下文，减少跨 P 通信。
9.2 findRunnable 的查找优先级
go复制func findRunnable() (gp *g, inheritTime bool) {
// 1. 从本 P 的 runnext 拿
// 2. 从本 P 的 runq 拿
// 3. 从全局队列批量拿
// 4. 从 netpoll 拿可执行 G
// 5. 从其他 P 偷一半任务
// 6. 仍没有则休眠/自旋
}
真正实现里还有很多细节，比如在全局队列取 G 时会限制次数防止某些 P 总是被跳过；netpoll 会返回一组就绪 G 而非单个；work stealing 也不是一次只从一个 P 拿，而是会把所有 P 轮询一遍。理解这个顺序，对排查“为什么这个 G 迟迟不执行”很有帮助。
9.3 调度循环的核心
go复制func schedule() {
// 找到 g
gp := findRunnable()
execute(gp) // 设置状态，gogo 跳入 g 的执行现场
}
// gogo 是汇编实现的上下文切换
// G 退出或阻塞后，会回到 g0 栈继续 schedule()
这段流程是 GPM 的“心脏”。日常开发中，除非你是 runtime 开发，否则不需要真的改这段逻辑，但知道它的存在能帮你理解为什么 goroutine 没有优先级概念，以及为什么调度顺序不能完全由代码控制。
如果你对 GPM 模型的理解只停留在概念层面，建议找一份 Go 源码，把 proc.go 里的 schedule、findRunnable、runqput、runqsteal 这几个函数读一遍，参考上面的注释和查找顺序，很快就能建立“代码 <-> 概念”的映射。我曾经带着团队做了一次源码阅读，每人讲解一个函数，效果比单纯听我讲一小时好得多。
10. 最后再分享一个我最常用的观测小技巧
线上环境不方便随时开 pprof 或 GODEBUG，我的做法是在 main 函数里默认启动一个不对外暴露的 net/http/pprof 服务，监听在 127.0.0.1 的一个随机端口，或者只在内网网卡上暴露。
go复制import _ "net/http/pprof"
go func() {
http.ListenAndServe("127.0.0.1:6060", nil)
}()
这样出事时可以直接从本机拉 goroutine 堆栈，不用临时加代码重新发布，也不会被外部访问到。我处理过多次突发 goroutine 泄漏，这个不起眼的几行代码救了大急。
回到开头那次事故。后来我发现，阻塞的 channel 之所以一直没被消费，是因为有一个本该被 main goroutine 调度的后置任务，被一个死循环中的 goroutine 饿死了——在老版本运行时下，那个死循环根本没有给调度器任何抢占机会。升级到新版 Go 并调整了任务分发逻辑后，问题就再也没有出现过。
希望这篇梳理能让你对 Go 调度器 GPM 模型不再只有“三个字母”的模糊印象。等你在实际排障中再看到 goroutine 数量飙升或者服务卡顿，能第一时间想到：先别慌，去看运行时是哪个环节堵住了。这比背多少调度器概念都更有用。