Go 语言中 runtime 调度器的 M 线程休眠与唤醒流程

聊聊 Go 调度器里一个非常核心的机制：M（操作系统线程）到底是怎样睡过去，又怎样被叫醒的？这里面有不少细节，稍不留神，你的程序性能就可能会在不知不觉中掉下去。

M 进入休眠前，必须释放 P 吗？

答案是肯定的，而且这是一条铁律。一个 M 要想进入 OS 线程的休眠（比如执行 epoll_wait、nanosleep 或者做一个阻塞的系统调用），必须先把它手里那个 P 交出来。

为什么这么绝对？核心原因其实不复杂：一个 P 同一时间只能被一个 M 持有。Go 语言允许创建大量的 M（远超 CPU 核心数），如果某个阻塞的 M 一直占着 P 不放，那其他已经准备好的 G 就只能干等着，完全没有机会运行。

完整的流程大致是这样的：schedule() 先看看队列里有没有 G 可跑，如果没有，就调用 stopm()。在 stopm() 里，它会显式地调用 handoffp() 把 P 归还给调度器，然后才去调用 notesleep() 真正地进入休眠状态。

• 一个很容易踩到的坑：当程序报出 runtime: m0 has no p 或者卡在 findrunnable() 里死循环时，多半是在某处绕过了 handoffp() 流程。
• 当然，凡事都有例外。sysmon 这个线程比较特殊，它从来不绑定 P，也根本不参与常规调度过程，所以它不会走这套休眠的逻辑。
• netpoll 在阻塞等待时（比如 epoll_wait）也遵循这个规则：必须先归还 P，然后才能安心等待网络事件。

唤醒 M 的两种主要触发方式

Go 调度器不会用外部信号去“主动”叫醒一个正在睡觉的 M，而是采用事件驱动的方式。要么是有了新的、等待执行的 G，要么是系统层面发生了需要处理的事件（比如网络 I/O 完成了）。唤醒的本质，就是让一个休眠的 M 重新拿到 P，然后开始执行 schedule()。

其中，startm() 是一个关键入口函数。它会从空闲的 M 列表（注意，这里说的是“列表”，可以是 allm 中的 next 链，也可以是 idlems）中拉一个 M 出来，然后尝试给它分配一个 P。是否能真的唤醒，完全取决于当时有没有可用的 P，以及是否需要新建一个 M。

• 网络 I/O 完成： 当 netpoll() 函数返回后，它会调用 injectglist() 把准备好的 G 放入全局队列或某个 P 的本地队列里。接着，通过 addtimer(&netpollTimer) 或者直接调用 startm(nil, false) 来尝试唤醒一个空闲的 M。
• 新 Goroutine 创建： 当你创建一个新的 G 时，如果当前没有空闲的 P 可用，那么创建操作可能会触发 startm() 来尝试新建或唤醒一个 M。
• 一个很重要的理解是：唤醒不等于立即执行。一个 M 被 notesleep() 唤醒后，它还得去和其他活跃的 M 竞争一个 P。如果竞争失败，它会再次乖乖地进入休眠。

为什么有时 M 睡下了，却迟迟不被唤醒，即便有 G 就绪？

这个问题的根源通常不在唤醒机制本身，而在于 P 的数量不足，或者 P 的分配出现了延迟。别忘了，Go 语言默认限制了最大 P 的数量为 GOMAXPROCS，所有处于就绪状态的 G，都必须依附于一个 P 才能执行。

举个具体的例子：假设 GOMAXPROCS=4，已经有 4 个 M 各自持有一个 P，并且在执行计算密集型的循环。这时新创建了一个 G 并加入了全局队列，但已经没有空闲的 P 可以分配了。此时，startm() 就不会被触发，进程看起来就像“卡住”了一样。

• 典型表现： 你用 runtime/pprof 抓取 goroutine 分析时，会发现大量 G 处于 runnable 状态，但 CPU 使用率却很低。
• 建议排查方向： 检查一下 GOMAXPROCS 的值是否被意外设置成了 1。另外，也要留意是否存在某些长时间的 Cgo 调用，并且没有调用 runtime.UnlockOSThread()，这会导致 P 被长期占用而不释放。
• 性能影响： P 不足会人为地制造调度瓶颈。就绪的 G 只能排在队列里等待，系统的尾延迟会被显著拉高。

调试 M 休眠与唤醒行为的实用手段

Go 运行时本身并不直接提供“这个 M 睡了多久”这种指标，但这并不意味着我们无从下手。通过组合一些工具和日志，我们还是可以定位到异常的休眠点。

最常用的方法就是开启调度器跟踪：GODEBUG=schedtrace=1000。这个命令会让程序每秒打印一次调度器状态，你可以清晰地观察到 M 的数量、P 的数量、G 的状态分布。尤其要关注 idle 和 dead 的 M 数量是否在持续增长。

• 系统调用跟踪： 用 strace -p -e trace=epoll_wait,nanosleep,clone 命令，可以直接观察操作系统层面的线程是否真的在休眠，以及休眠了多长时间。
• 代码插桩： 在关键的代码路径上，可以手动插入 runtime.ReadMemStats() 配合时间戳，来辅助判断程序是否在调用 stopm() 后一直没有被唤醒。
• 需要特别注意的是，pprof 的 goroutine profile 捕获的是瞬间的快照，它无法反映 M 的休眠历史。要分析这个问题，必须结合 schedtrace 和系统调用跟踪来交叉验证。

实践中，最让人头疼的往往是“P 被隐式占用”导致唤醒链断裂的情况。比如 Cgo 函数忘记解锁线程，或者 syscall.Syscall 返回后没有及时调用 acquirep()。这类问题不会抛出任何错误，调度器只会默默降频，让你的程序性能慢慢变差，非常隐蔽。