空闲M不立即回收是为了避免高开销的OS线程频繁创建/销毁，runtime默认等待约2秒确认真正空闲后才释放资源，优先复用idle M以换取调度响应速度，该策略与GC不立即归还内存同属“用空间换时间”设计。
空闲 m 不会立刻被销毁，而是进入 idle 状态等待复用；runtime 默认只在持续空闲数秒后才真正释放线程资源。
为什么空闲 M 不能马上回收
OS 线程创建成本高（栈分配、TLS 初始化、内核调度注册），频繁新建/销毁会拖慢调度响应。Go runtime 优先复用 idle M，而不是每次有新 G 就拉起新 M。这和 runtime.GC() 不立即归还内存给 OS 是同一类设计逻辑——用空间换时间。
常见误判场景：
- 看到
pprof -threads中线程数居高不下，以为是泄漏，其实只是 M 在 idle 队列里待命 - 用
ps -T -p <pid></pid>观察到大量线程，但runtime.MemStats.MNumThread显示数值稳定，说明这些线程已被 runtime 管理并休眠
runtime 回收 idle M 的具体条件
一个 M 要被真正“回收”（即调用 pthread_detach 并释放栈），必须同时满足：
- 当前未绑定 P（已解绑或 P 已移交）
- 未被
runtime.LockOSThread()锁定 - 不在 cgo 调用上下文中（cgo 派生的 M 由 C 侧生命周期主导）
- 处于 idle 状态超过约 2 秒（实际阈值由 runtime 内部定时器控制，不可配置）
注意：runtime/debug.SetGCPercent(-1) 或手动触发 runtime.GC() 对 M 回收无影响——M 生命周期完全独立于 GC 周期。
如何观察 M 的增减与 idle 状态
最直接的方式是启用运行时追踪：
GODEBUG=schedtrace=1000 ./myapp
每秒输出类似：
SCHED 0ms: gomaxprocs=8 idleprocs=2 threads=15 spinningthreads=0 mcount=15 mcachecount=8
其中 threads 是当前 OS 线程总数，mcount 是 runtime 认知中的 M 总数（含 idle），idleprocs 是空闲 P 数量（间接反映 M 是否有活干）。若 threads > mcount，说明有线程是外部引入（如 cgo 或 exec.Command）。
也可通过 pprof 查看：
go tool pprof http://localhost:6060/debug/pprof/threadcreate
该 endpoint 统计的是 M 创建事件，不是实时线程快照。
容易被忽略的关键点
真正难调试的不是“M 回收太慢”，而是“M 根本没机会 idle”。比如：
- 大量 goroutine 频繁阻塞在系统调用（如
net.Conn.Read未设超时），导致 M 长期卡在 syscall 中，不进 idle 队列 - cgo 调用中嵌套 Go 回调，且回调里又启动新 goroutine，可能意外创建不受控的 M
- 使用
os/exec.Command启动子进程时，若 stdout/stderr 未消费完就 Wait，其内部 pipe reader 可能长期占用 M
这些情况会让 threads 持续上涨，但不是 runtime 回收机制失效，而是 M 始终不满足 idle 条件。
