空闲m不会被立即回收，因为runtime仅在m解绑p、未锁定、未系统调用且连续空闲数秒以上时才将其置idle并释放线程资源；gomaxprocs不约束阻塞态m，http长连接等常见场景使其滞留，freeosmemory对m无任何影响。
go runtime 不会主动回收空闲的 m（os 线程），除非满足严格条件；盲目调高 gomaxprocs 或放任系统调用堆积，反而会导致线程数暴增、cpu 调度抖动加剧。
为什么空闲 M 不会被立即回收
空闲 M 的“回收”本质是休眠 + 线程资源释放，但 runtime 设计上极度克制：只有当 M 同时满足以下全部条件时，才可能被置为 idle 并最终调用 pthread_detach：
-
M当前未绑定任何P（即已解绑） -
M未被runtime.LockOSThread()锁定 -
M未处于系统调用中（如read、accept、epoll_wait） -
M连续空闲时间足够长（具体阈值未导出，但实测通常需数秒以上）
最常见卡点是：HTTP 长连接、数据库连接池空闲等待、time.Sleep 中的定时器唤醒逻辑，都会让 M 停留在“可运行但无 G”状态，不触发回收。此时 ps -T -p $PID | wc -l 显示的线程数会持续高于 GOMAXPROCS。
GOMAXPROCS 对 M 数量的实际约束力很弱
GOMAXPROCS 只限制「同时执行用户 Go 代码」的 M 数量，对阻塞在系统调用中的 M 完全不设限。这意味着：
- 一个 HTTP server 在处理 1000 个并发
read等待时，可能瞬间创建 1000+ 个M，哪怕GOMAXPROCS=4 - 这些
M一旦从系统调用返回，若没及时被调度器复用，就会滞留为 idle 线程 -
pprof中runtime.mcall或runtime.futex占比高，往往就是大量M在轮询/等待中空转
验证方式：go tool pprof http://localhost:6060/debug/pprof/threadcreate?debug=2 查看线程创建频次；配合 cat /proc/$PID/status | grep Threads 观察实时线程数趋势。
如何真正减少空闲 M 并压低 CPU 负载
关键不是“等回收”，而是从源头减少不必要的 M 创建和阻塞：
- HTTP 客户端务必设置
Timeout和Transport.IdleConnTimeout，避免连接长期挂起 - 数据库连接池启用
SetMaxIdleConns和SetConnMaxLifetime，防止空闲连接拖住M - 避免在 goroutine 中裸写
for { time.Sleep(); doWork() }，改用time.Ticker+select配合ctx.Done() - 网络服务若需多核吞吐，不要靠增加 goroutine 数量，而应启动多个进程（SO_REUSEPORT）或使用
net/http.Server.ServeTLS分实例监听 - 检查是否误用
runtime.LockOSThread()—— 一旦锁定，该M永远不会被回收，且无法参与调度复用
特别注意：cgo 调用派生的 M（如 C 函数里调 go）完全绕过 runtime 管理，C 侧必须显式 pthread_exit 或确保线程复用，否则必然泄漏。
FreeOSMemory 和 M 回收毫无关系
这是最容易混淆的一点：runtime.FreeOSMemory() 只作用于堆内存（mheap），把闲置 span 归还 OS；它对 OS 线程（M）的生命周期零影响。调用它之后 ps 看到的线程数不会少一个，/proc/$PID/status 中的 Threads 字段也不会变化。
真正影响 M 数量的，只有调度器对空闲线程的 idle 判定逻辑、系统调用退出路径、以及 cgo 的线程管理责任归属。别指望靠内存操作“顺带”清理线程——它们是两套完全独立的资源管理体系。
