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。
