weixin_291976991. 为什么 Go 需要一个专门的调度器：从并发模型的无奈说起
你写 Go 的时候，一句 go func() 就能开出一个“并发任务”，简单得让人上瘾。但很多人用了一年两年，遇到线上高并发抖动、goroutine 数量飙升、程序莫名变慢，就开始意识到：并发好写，调度不好懂。我最早从 Java 转到 Go 时，也天真地以为 goroutine 就是“更轻的线程”，直到一次线上事故让我不得不钻进调度器的源码里去查，才发现自己之前对调度机制的认知基本是零。
先说结论：goroutine 必须有一个调度器，因为 Go 在语言层面选择了 M:N 两级线程模型。也就是说，Go 程序里成千上万个 goroutine，最终都跑在数量远小于它们的操作系统线程（M）上面。操作系统只认识线程，不认识 goroutine，谁去把 goroutine 分配到线程上执行，谁去在 goroutine 阻塞时切换别的 goroutine 来跑——这就是调度器干的活。
为什么 Go 不直接用系统线程做并发呢？这里有一个非常朴素的算账问题。你创建一个系统线程，光栈空间默认就要 8MB（Linux 上 ulimit 配的栈大小），线程切换时还要经过内核态，用户态和内核态的切换开销不是一般的大。而一个 goroutine 初始栈只有 2KB，创建成本极低，切换更是完全在用户态完成。简单粗暴地说：如果线程是一辆公交车，goroutine 就是一辆小电驴。公交车的运力虽然强，但你没那么多乘客要拉；小电驴灵活、便宜，但马路上总得有交警来指挥它们怎么走、什么什么时候该停。Go runtime 里的 scheduler 就是那个交警。
可是这个交警不是凭空想出来的。在早期，Go 的调度器模型是 G-M 两级模型：G 是 goroutine，M 是系统线程，运行时有一个全局锁来保护全局 goroutine 队列。听起来很简单对吧？但这个模型的吞吐量很低：每个 M 在执行 goroutine 前都要抢一把全局锁，在高并发下锁竞争极其严重，大量时间都耗在锁等待上。后来 Go 团队引入了 P（Processor）的概念，演变成现在的 G-M-P 模型，大幅减少了锁竞争。
所以你现在看到的 Go 调度器，本质上是一套为了“用尽量少的线程、跑尽量多的 goroutine，同时保持低延迟和高公平性”而设计出来的复杂系统。理解它，对你调优 Go 服务、排查性能瓶颈，以及应付 Go 面试题（你没看错，这真的是高频面试点）都有直接帮助。
这篇文章会结合源码层面和实际运行现象，把调度器从骨架到血肉拆开讲一遍：先看 G/M/P 三者怎么分工，再看 goroutine 完整的调度生命周期，之后是抢占机制和工作窃取怎么保证公平与效率，最后落到实战——在我排查过的线上问题里，调度器是如何直接导致性能抖动的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. G-M-P 模型：调度器的骨架，三个角色的分工与博弈
2.1 G、M、P 各自到底是什么
调度器的核心数据结构其实就三个字母：G、M、P。很多人背得住模型图，但不知道三者真正干什么，出了事情反而不知道看哪里。我用一句话总结每个角色的职责：
- G（Goroutine）：代表一个 goroutine。它包含栈、栈指针、PC（程序计数器）、当前 M、状态等。它是被调度的“任务”。
- M（Machine）：代表操作系统线程。它是真正在 CPU 上执行代码的载体，负责把 G 的代码跑起来。M 有它自己专属的 g0（调度栈栈，栈上的代码是调度器自身逻辑），持有本地缓存，还可能因为系统调用而阻塞。
- P（Processor）：代表调度上下文。它是连接 M 和 G 的中间层，每个 P 有一个本地可运行 G 队列（runq），因此 P 是“调度单位”的关键——一个 M 想跑 G，必须先绑定一个 P；P 决定了可以同时运行的 G 数量上限。
一个很容易混淆的点是：P 不是 CPU 核心，它是逻辑处理器。Go 程序里，GOMAXPROCS 决定的是 P 的数量，而不是线程上限。正常情况下，P 的数量等于可以被并行执行的 goroutine 数量上限。你可以理解成 P 是停车位，M 是司机，G 是乘客。司机（M）想拉客跑路（执行 G），必须先有车位（P）。没有 P 的话，M 就只能歇着或者去干活儿。
默认情况下，P 的个数等于 CPU 逻辑核心数。但你注意：这里有一个非常关键的坑——在容器环境里，Go 在旧版本里可能读到的是宿主机的核心数，而不是容器的配额，这就导致创建了大量 P，调度器以为自己可以并行跑很多 goroutine，实际上 CPU 时间被配额卡死，性能反而变差。这个我后面实战部分展开。
2.2 G 的状态流转：从创建到消失
G 的状态是理解调度器运行机制的地基。G 的状态非常多，但核心就几个，而且它们之间的转会关系是调度器行为的直接体现：
_Gidle：刚分配，还没初始化。_Grunnable：可运行，等待被 M 执行。通常它已经挂到了某个 P 的本地队列或全局队列里。_Grunning：正在被执行。G 会关联到一个 M 和一个 P 上。_Gsyscall：正在执行系统调用（比如文件读写、网络 IO 阻塞在内核里）。此时 M 被系统调用占用，但 P 可能已经被转让给别的 M 了。_Gwaiting：阻塞中，等待某个条件满足（比如 channel 接收、锁等待、定时器）。这种状态不占用 CPU，也不需要 M。_Gdead：已经执行完或刚初始化，可被复用。_Gcopystack：栈扩容或缩容时临时出现，表示正在拷贝栈。
这里最值得玩味的是 _Grunnable 到 _Grunning 的变化：它发生了无数次，背后的核心就是 schedule() 和 execute() 这两个函数。调度器从当前 P 的本地队列或者全局队列里拿一个 G，把它设成 _Grunning，然后通过 gogo 跳转过去执行。当 G 需要等待或让出时，它又会被挂起、放回队列，回到 _Grunnable 或者 _Gwaiting。整个过程完全在用户态完成，不涉及内核线程上下文切换——这也是 goroutine 切换能以微秒级计时的根本原因。
2.3 本地队列和全局队列：一份工作，两个“候车区”
每个 P 有一个本地可运行队列（runq），它实际上是一个数组和索引组成的环形队列，容量是 256。当你在业务代码里执行 go func() 时，新建的 G 并不是直接丢给全局调度器，而是先放进当前 P 的本地队列的 runnext 槽位——这是一个特殊优化：runnext 优先被调度执行。
这个设计是有讲究的。新创建的 goroutine 往往是当前 goroutine 的后继任务，比如它正在执行一个循环，每次迭代都 spawn 一个 goroutine，那么让新 G 优先执行可以提高缓存局部性，同时降低调度延迟。如果 runnext 已经被占，才放到本地队列尾部；如果本地队列满了，就把其中一半 G 转移到全局队列。
全局队列（sched.runq）则是兜底的。本地队列有容量限制，而且每个 P 只管自己的本地队列，跨 P 的动态负载平衡就是靠工作窃取完成的（后面专门讲）。全局队列里的 G 只有本地队列没货时才会被拿到。这里还有一个细节：全局队列是按优先级轮询的，每 61 次调度，就会从全局队列拿一次 G，防止全局队列饿死。
你可能会问：这样设计有什么好处？一句话概括就是：先把任务留在“自己手里”，减少跨线程的数据竞争和锁开销。如果每个 goroutine 都先往全局队列丢，那所有 P 抢同一个队列锁，性能会退化得非常严重；而本地队列的设计让大部分调度操作都发生在 P 内部，只有队列满了或者空了才碰全局结构。
3. 调度循环：一个 goroutine 从出生到执行完的完整旅程
3.1 从 go func() 到真正执行：中间发生了什么
你写 go func() {} 时，编译器会把它转换成一个运行时调用，底层最终走到 newproc -> newproc1。newproc1 干了几件事：
- 从当前 M 的缓存里尝试取出一个空闲的 G（因为 G 是可以复用的），如果没有就
malg分配一个，初始栈大小 2KB； - 把函数入口地址、参数、返回地址等写入 G 的栈和寄存器上下文；
- 设置 G 的状态为
_Grunnable； - 调用
runqput，把这个 G 放进当前 P 的本地队列或全局队列。
注意第 4 步：它并没有直接唤醒一个 M 去执行。真正的执行要等某个 M 进入调度循环，从队列里把这个 G 拿出来跑。
那么谁会把刚创建出来的 G 执行起来？可能是当前 M 的调度循环空闲下来后拿；也可能是别的 P 的执行线程窃取；还有一种情况：当前 M 正在执行别的 G，队列里积压了大量任务，可能已经有空闲 M 或 P 来偷。总之，执行时机完全是调度器按需决定的。
我刚学 Go 的时候有个误解：go func() 之后这个过程是不是马上并行执行？答案是否定的。go func() 的开销很低，只负责入队，真正的执行是在调度器“看心情”的时候进行的。如果你在循环里密集地 go func()，尤其是 CPU 密集任务，最终的表现可能接近串行，因为并行上限是 GOMAXPROCS。
3.2 核心调度函数：找活儿干的优先级链路
在 M 绑定 P 之后，调度器会不停执行 schedule() 循环，里面的核心是 findRunnable()。这个函数就是整个调度器最聪明的地方——它找工作的顺序非常有讲究，官方源码注释很长，我把它核心路径简化一下：
- 从 P 的本地队列里拿，先看
runnext（这是最快路径，不加锁或轻量锁）； - 本地队列（runq）里拿；
- 从本地队列拿不到时，看一下全局队列；
- 全局队列也没有，去看看网络轮询器（Netpoller）有没有就绪的网络任务可拿；
- 都没有，开始
work stealing，随机找别的 P，从它的本地队列偷一半 G 过来； - 还偷不到，检查全局队列有没有新的任务；
- 实在没活儿，就进入空闲状态，M 会 park 休眠，等信号唤醒。
这个优先级顺序不是随便定的：本地最快、偷取次之、全局最后、阻塞最差。缓存亲和性是最重要考量——本地队列里的 G 大概率跟当前 P 的 L1/L2 缓存有友好的数据关系，换到别的 P 上缓存就废了。所以没事别乱 runtime.Gosched()，它虽然能让出当前 M，但也会打断这种亲和性。
3.3 阻塞、系统调用与唤醒：调度器的“停车换道”
goroutine 执行过程中最麻烦的是阻塞。这里的核心哲学是：绝不让操作系统线程白白等在一个 goroutine 的阻塞上。
如果 G 的执行体主动陷入 channel 等待、锁等待等非系统调用型阻塞，调度的逻辑比较简单：G 进入 _Gwaiting，M 立刻通过 schedule() 换下一个 G 来跑，P 不会被释放。因为这种阻塞只涉及 goroutine 本身，M 这个线程没有陷进内核。
难点在系统调用阻塞，比如你执行一个普通的文件 Read 或 Write，底层是 syscall，如果这个调用会阻塞，那整个 M 线程都被阻塞在内核里了，P 不能跟它一起干等。Go 的解决方案是：进入系统调用前，会通过 entersyscall 把当前 G 标记为 _Gsyscall，P 会被显式标记为“系统调用中”；系统调用结束前，exitsyscall 会尝试重新绑定 P——如果绑定失败（比如这个 P 已经被其他 M 抢走了），就把 G 重新丢回可运行队列，M 自己去休眠或找别的 P。
更细一步：Go 会在 entersyscall 之后检查当前 P 是否可以被释放。如果 M 陷入阻塞的时间够长（超过一个阈值，由 sysmon 监控），另一个空闲 M 就会接管这个 P，继续从 P 的本地队列拿 G 执行。因为 Go 的很多系统调用都被改造为“非阻塞”模式了（尤其是网络 IO，走 Netpoller），所以你日常写业务代码很少感知到这个切换过程，但它确确实实在背后高频发生。
举个实际场景缓解一下理解难度：假设你有 8 个 P（GOMAXPROCS=8），其中 3 个 M 因为文件 IO 阻塞在内核里，但系统调用时间比较长，sysmon 发现后会把它们的 P 剥离，交给 2 个空闲 M 和新创建的 M 继续执行队列里的任务。此时你的程序虽然只有 8 个“逻辑处理器”，但实际可能同时存在 10 个 M，其中 3 个卡在系统调用里不能干活。这算不算坏事？不算。只要 P 没有闲着，调度效率就是及格的。M 多开本身开销不小，但不至于灾难；真正要警惕的是大量 M 都阻塞在系统调用上，导致线程数和内存都爆掉——这就是 goroutine 泄漏和系统调用泄漏的常见后果。
4. 抢占、Netpoller 与工作窃取：调度器如何“既要公平，又要效率”
4.1 从协作式到异步抢占：Goroutine 不能“占着茅坑不拉屎”
在 Go 1.14 之前，调度器的抢占是协作式的。协作式是什么意思？就是当前 goroutine 必须自己主动让出，比如发生函数调用、GC 栈扫描、进入系统调用等“安全点”，调度器才有机会切走它。如果一个 goroutine 陷入死循环，而且循环体里没有函数调用和系统调用，那么这个 goroutine 会一直霸占 M，其他 goroutine 包括 GC 都只能干等。这在 CPU 密集场景下是灾难：你写了一个 for {}，整个 runtime 基本卡死，连 go func(){fmt.Println("hello")}() 都没机会执行。
Go 1.14 引入了基于信号的异步抢占。sysmon 线程会监控每个正在运行的 G，如果发现它运行时间超过 10ms（可以理解为一个调度时间片），就会向那个 M 发送抢占信号。收到信号后，go 的 signal handler 会把正在执行的 G 标记为可抢占，并在安全点插入栈增长检查（stackPreempt 标志），从而强制让它让出 CPU。你不需要了解每个细节，只需要记住：现在即使是纯计算型死循环，调度器也有办法打断它，让别的 G 有机会运行。所以别在 Go 里用 runtime.GOMAXPROCS(1) 测试死循环时期待它像老分布式系统一样“卡死”——现在的调度器硬得多。
但是，异步抢占不是免费的。每次抢占都会触发信号处理、栈信息保存、状态转换，开销比协作式切换大不少。所以 Go 团队在设计时做了大量优化：在函数序言检查抢占标志，而不是每个指令都检查；只在必要时发信号；细粒度的栈扫描只在 GC 和栈扩容时做。这种设计也提醒我们：大量短期 CPU 密集型 goroutine 反而可能比少量长时间 goroutine 效率低，因为频繁抢占切换会带来不少开销。
4.2 Netpoller：网络 IO 为什么“不阻塞线程”
Go 的网络 IO（比如 HTTP 请求、net.Dial、net.Conn.Read）是非常经典的非阻塞模型。你写一个 conn.Read，如果数据没到，这个 goroutine 会沉睡，但 M 不会被占住——这时 Netpoller 就出场了。
Netpoller 是运行时里负责监听网络可读/可写事件的组件。它使用操作系统的 IO 多路复用机制（Linux 上是 epoll，macOS 上是 kqueue，Windows 上是 IOCP），统一监听所有网络 fd。当一个 goroutine 发起网络 IO 时，运行时把这个 fd 注册到 Netpoller，然后该 G 进入 _Gwaiting。M 立刻被调度器拿去执行别的 G。当 IO 事件到达时，epoll 通知 Netpoller，它把对应的 G 标记为就绪，放入某个 P 的本地队列或全局队列，等待被调度执行。
这就是为什么 Go 网络编程天然支持高并发：你开一万个 TCP 连接，每个连接一个 goroutine 读数据，底层 epoll 只是监听这些 fd，真正的线程数量完全由 GOMAXPROCS 和系统调用阻塞情况决定。Netpoller 的唤醒时机是 findRunnable 第 4 步——本地和全局队列都没有任务时就去查网络事件，这保证了网络 IO 的延迟不会太高。
有一个值得注意的极端情况：如果你写的是一个纯计算型服务，完全没有网络 IO，那 Netpoller 基本是空转；但如果你的服务是大量读请求加少量等待，Netpoller 的介入频率就非常高，此时调度器必须更快地从网络事件里唤醒 G。用 go tool trace 观察时，如果发现一段时间里 Syscall/Network 事件特别密，就能看出来。
4.3 工作窃取：不让任何 P 闲着，也不让任何 P 累死
工作窃取是整个 G-M-P 模型里最能体现调度器“聪明”的点。当某个 P 的本地队列空了，它不会立刻陷入 idle 状态，而是随机挑选别的 P，偷取对方本地队列里一半的 G 过来执行。
这里有个细节：偷的时候不是直接把对方队列拿空，而是拿一半（大约一半）。为什么？如果偷光了，对方 P 很快也会面临空队列，然后它再反过来偷，导致大量无效的窃取操作；只拿一半既能均分负载，也降低了对原 P 的扰动。源码里 runqsteal 就是干这个的，它从目标 P 的队列尾部偷走大约一半任务，放到自己队列头部。
被偷走的 G 会失去原 P 的缓存亲和性，所以工作窃取只在必要的时候才做——你本地队列空着，继续等也不会有新任务，才值得去偷。这也说明为什么在负载均衡、任务分配上，很多调度器都借鉴了这种“局部优先 + 全局兜底 + 随机窃取”的模式：它兼顾了低延迟、高吞吐和公平性。
工作窃取还有一个衍生优点：它天然支持“任务并行化”。比如你用 sync.WaitGroup 发起了 10000 个 goroutine，它们分布在多个 P 的本地队列里，执行快的 P 会自动从执行慢的 P 那里偷任务，最终所有核的完成时间趋于一致。你不需要手动做任何分片和负载均衡，Go 调度器帮你干了。
4.4 饥饿与公平：全局队列的“定期检查”机制
队列如果完全按本地优先执行，极端情况下会造成不公平：某个 P 的本地队列一直有活儿，它永远不会去看全局队列，全局队列里的任务就“饿死”了。所以 Go 调度器在 schedule() 里做了这么一件事：每 61 次调度，就强制从全局队列里取一个 G。
这个 61 是硬编码的，为什么选 61？因为它是质数，能尽量保证周期性检查不被本地队列任务产生规律“共振”。这就是调度器设计中的“有心机”之处——你看着像是简单的随机/轮询，实际每一步都有对抗极端场景的考虑。
另外，全局队列也有长度限制，runqput 在本地队列满时会转移一半任务到全局队列，全局队列本身是无上限的，但持有 sched.lock 全局锁，性能和竞争都要注意。所以尽量不要通过手动的方式往全局队列塞任务，正常写 Go 代码几乎不会直接碰全局队列，它是调度器内部逻辑。
5. 调优与踩坑：从调度器机制看线上性能问题
5.1 GOMAXPROCS 到底怎么设置
我曾经在一个高并发网关服务上遇到诡异现象：本地压测 8 核机器吞吐很稳，部署到 16 核容器里反而延迟抖动变大了。后来排查发现，容器 cpu.cfs_quota_us 限制为 200ms/100ms（即 2 核配额），但 Go runtime 启动时读取 /proc/cpuinfo 得到 16 核，于是 GOMAXPROCS=16，运行时创建 16 个 P。结果就是，调度器以为自己有 16 个执行槽位，疯狂并行调度 goroutine，但内核实际只给 2 核的 CPU 时间，大量线程在等待 CPU 时间片，上下文切换和 goroutine 抢占频繁，性能雪崩。
解决办法就是正确设置 GOMAXPROCS。几个经验值：
- 如果你的服务是纯粹的 CPU 密集型计算（比如加解密、压缩、图像处理），GOMAXPROCS 设为可用 CPU 核心数即可，不需要大于核心数。
- 如果你的服务主要是 IO 密集（网络请求、数据库等待），GOMAXPROCS 不要超过核心数太多，通常等于核心数或者略小，因为大量 IO 等待的 goroutine 不占用 CPU，线程本身能被调度器复用。
- 容器环境下，别偷懒，一定要用
automaxprocs库（比如 uber 出的那个）在 main 里 import 一下，它会读取 cgroup 的 CPU 配额并自动设置 GOMAXPROCS。
具体到代码里，你可以运行 runtime.GOMAXPROCS(0) 查询当前值，也可以通过环境变量 GOMAXPROCS 手动指定。我个人的实践是：业务服务里强制用 automaxprocs，避免上线后运维不统一导致每个实例跑出来效果不一致。
5.2 goroutine 数量暴涨：不是并发能力强，是调度器在求救
这是我在面试中最喜欢问的一个问题：goroutine 数量从几千涨到几百万，你的程序会不会崩？很多人以为 Go 可以创建百万 goroutine 就是“无限并发”，实际上每个 goroutine 初始栈 2KB，一百万个就是 2GB 虚拟内存，再加上调度器开销、GC 扫描，内存和 CPU 会同时爆炸。
真正的线上问题往往不是 goroutine 创建太多太快，而是创建的 goroutine 一直阻塞不退出，运行时的 M 和 P 都没问题，但 GC 扫描 G 耗费巨量时间，业务延迟变成几十秒。典型原因包括：
- channel 没有消费者或没人 close，接收方永久阻塞；
sync.Mutex被持锁的 goroutine 卡死（比如持锁后死循环或等待不存在的条件）；time.Ticker创建后没有 Stop，导致泄漏；- 对不可达的等待条件使用
select空等； - SQL 连接池耗尽，大量 goroutine 排队等待连接；
- 一个 fd 读阻塞，但没人关闭它。
排查时，除了用 pprof 看 goroutine 栈分布，还要记得看 runtime.NumGoroutine() 的曲线。如果你发现 goroutine 数量线性增长，基本可以确定有 goroutine 泄漏，而不是调度器本身的问题。从我经验看，80% 的 goroutine 泄漏都跟 channel 和锁有关，所以写代码时要养成 select 超时、context.Context 取消、defer close 的习惯。
5.3 锁竞争和原子操作对调度的“隐形干扰”
有时候你的服务 CPU 使用率很高，但吞吐量很低，你可能先怀疑算法效率，实际上可能是调度器的隐形成本。尤其是大量 goroutine 在抢同一把锁时，M 会频繁 park/unpark，涉及操作系统线程调度，开销非常大。
举一个真实例子：一个日志服务里，每个请求都会写一份业务日志到同一个文件，代码里用全局 sync.Mutex 保护写入。压测时发现延迟抖得厉害，后来用 go tool pprof 看 CPU profile，热点排在前面的是 sync.(*Mutex).Lock 和 runtime.futex。原因就是每个请求的 goroutine 都来抢锁，抢不到的被挂起，抢到的写完后唤醒下一个，导致线程频繁切换。
这个问题的本质不是锁本身，而是锁粒度太大和太多 goroutine 竞争。优化方案通常是把日志写入改为异步队列：业务 goroutine 把日志结构体投递到 channel 或 ring buffer，一个后台 goroutine 批量写盘。你会发现，把锁竞争挪到 channel 之后，调度压力小了很多，因为 channel 的收发在用户态处理，而且批量写大幅减少了磁盘 IO 唤醒。
5.4 实战排查工具：schedtrace、pprof 与 trace
调度器本身是黑盒，但 Go runtime 给了几个观测手段，强烈建议你学会。
第一个是 GODEBUG=schedtrace=1000。运行程序时设置这个环境变量，每 1000 毫秒打印一行调度器状态，包含当前 GOMAXPROCS、空闲 P 数、线程数、队列长度等。它的作用不是你平常拿来看的，而是当你怀疑调度器行为异常时，用它快速判断是不是 P 数设置不合理、线程数是否过多、G 是否大量堆积在全局队列。
第二个是 net/http/pprof 的 goroutine profile。go tool pprof http://localhost:6060/debug/pprof/goroutine 可以直接抓到所有 goroutine 的堆栈。你会看到大量 goroutine 卡在同一个等待点上——这就定位到泄漏或者排队问题了。
第三个是 go tool trace。它可以展示每个 P 上执行的 goroutine、调度事件、网络事件的时间线。对于想从“时序”上理解调度器行为的人来说，这个工具是可视化的神器。比如你想看某段时间内有没有 P 一直在空转（没有 G 执行），看 trace 里 P 的 running 段和 idle 段分布就很直白。
我通常的排查流程是：先用 pprof 确认 goroutine 数量是否异常，再用 trace 看调度事件是否频繁，接着看是不是锁竞争或者系统调用阻塞，最后才考虑是不是 GOMAXPROCS 没设置对。这个顺序能避开大部分误判。
6. 一些值得记住的“反直觉”经验
最后讲几个我在实际写 Go 代码中踩过、调试过、甚至被坑过才总结出来的经验，它们和调度器机制直接相关。
反直觉一：runtime.Gosched() 不是万能的“让出”手段。 很多人写 CPU 密集循环时想用 Gosched 让别的 goroutine 跑，但它的作用仅仅是让出当前 M，让该 M 重新从调度器队列拿新 G。如果当前 M 绑定的 P 本地队列里还有别的 G，它可能立刻又拿起来跑；而且频繁调用 Gosched 还会打乱缓存亲和性，得不偿失。正确的做法是：让调度器通过抢占机制自动切换，不要在业务代码里手动干预。
反直觉二：goroutine 的创建和销毁并不“免费”。 虽然创建成本很低（微秒级），但大量 goroutine 进出调度队列、GC 扫描它们，累计开销非常可观。一个经验值是：如果单一请求要创建超过几百个 goroutine，你该考虑用 goroutine 池或者分片任务了。过度使用 goroutine 并不会让程序变快，反而可能因为调度开销和内存占用变慢。
反直觉三：GOMAXPROCS 不等于“并行上限”。 它决定的是 P 的数量，也就是“同时处于运行状态的 goroutine 数量上限”，而不是你能创建的 goroutine 数上限。你可以创建百万 goroutine，但同一时刻真正在跑的只有 GOMAXPROCS 个。真正限制你系统吞吐的往往是 CPU 核数、内存带宽、锁竞争和系统调用，而不是 GOMAXPROCS 太小。
反直觉四：Go 的抢占不是“绝对精确”。 基于信号的异步抢占在 10ms 左右触发一次，但实际切走一个 G 需要它运行到安全点。如果一个 G 正在执行一段特别长的无栈检查代码，抢占可能有延迟。所以在写需要低延迟响应的服务时，尽量别做超长的 CPU 密集运算——把它拆分成小任务或者交给 worker pool，不要让单个 G 长时间霸占 P。
Go 的调度器这些年一直在演进：从 G-M 到 G-M-P，从协作式抢占到异步抢占，从简单轮询到工作窃取和 Netpoller 协同。演进的方向始终是同一个：用更少的系统资源，承载更多的并发任务，同时保证延迟和公平。你不需要把每个源码函数都背下来，但理解 G-M-P 模型、调度循环、抢占机制和工作窃取这些核心思想，对你日常写并发代码、排查性能问题，带来的收益是实打实的。