Go 语言中 runtime 调度模型中 M 的创建与回收机制

在Golang实战开发的过程中，我们经常会遇到一些这样那样的问题，然后要卡好半天，等问题解决了才发现原来一些细节知识点还是没有掌握好。今天golang学习网就整理分享《Go 语言中 runtime 调度模型中 M 的创建与回收机制》，聊聊，希望可以帮助到正在努力赚钱的你。

M是OS线程，即Go运行时对操作系统内核线程的抽象封装，直接对应pthread等内核线程，由runtime自动管理创建与回收，必须绑定P才能执行G，无用户可见API。

M 是什么：OS 线程，不是 goroutine

Go 的 M（Machine）是 runtime 对操作系统线程（OS thread）的抽象封装，它直接对应一个内核级线程（如 Linux 上的 pthread）。M 的生命周期由 runtime 完全管理，但它的创建和销毁不透明——你无法用 Go 代码直接 new 或 free 一个 M，它只在调度需要时由 runtime 自动拉起或回收。

常见误解是把 M 当成可编程对象；实际上，M 没有公开 API，也不暴露给用户代码。它的存在只为承载 G（goroutine）执行，且必须绑定到一个 P（Processor）才能工作。

runtime 何时创建新 M

runtime 在以下几种场景会主动创建新 M：

• 当前所有 M 都被阻塞（如系统调用、cgo 调用、网络 I/O 等），而本地 P 队列里还有就绪的 G 待运行，此时会启动新 M 来“解压”调度压力
• 程序刚启动时，runtime 初始化阶段会预创建少量 M（通常为 1~2 个），配合默认的 P 数量（GOMAXPROCS）启动调度循环
• 调用 runtime.LockOSThread() 后，若当前 M 已绑定其他线程，runtime 可能新建 M 来满足独占线程需求
• 某些系统调用返回后，runtime 发现原 M 无法快速恢复（如被抢占或状态异常），可能用新 M 接管其 P 和待运行 G

注意：M 创建开销不小（涉及 OS 线程创建、栈分配、TLS 初始化等），runtime 会尽量复用已存在的 M，而非频繁新建。

runtime 如何回收 M

M 的回收不是“销毁”，而是“休眠并归还线程资源”。当一个 M 长时间空闲（无 G 可运行、未被锁定、且未处于系统调用中），runtime 会将其置为 idle 状态，并最终调用 pthread_detach（Linux）或等效系统调用释放线程资源。关键点：

• 回收前会确保该 M 已解绑 P，且 P 已移交或进入自旋等待
• 被 runtime.LockOSThread() 锁定的 M 不会被回收，即使空闲也会一直驻留
• cgo 调用中派生的 M（即由 C 代码触发的 Go 调用）不会被 runtime 主动回收，需由 C 侧负责线程生命周期，否则可能泄漏
• 可通过 runtime.MemStats.MCacheInuse 或 pprof 中的 goroutine / threadcreate 事件观察 M 的增减趋势

容易被忽略的细节：M 与系统线程的映射不是 1:1 永久绑定

一个 M 在生命周期中可能切换绑定不同的 OS 线程（例如因信号处理、栈切换或调试器介入），而一个 OS 线程也可能在不同时刻被多个 M 复用（尤其在 strace 或 perf 观察时看到线程 ID 重复出现）。真正稳定的是 M → P → G 这条逻辑链，而非 M ↔ OS thread 的物理绑定。

这意味着：不要试图通过监控 /proc/pid/status 的 Threads: 行来精确推算活跃 M 数；也不要假设 runtime.NumGoroutine() 高就一定意味着 M 数暴涨——大部分 goroutine 在休眠或阻塞时并不占用 M。

本篇关于《Go 语言中 runtime 调度模型中 M 的创建与回收机制》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！