m不能由go代码创建或销毁，因其是runtime对os线程的底层封装，生命周期由c/汇编实现的调度逻辑严格控制，无公开api，且字段abi不保证兼容。
M 的创建与销毁完全由 runtime 自动管理，你无法通过 Go 代码直接 new 或 free 一个 M；它不是用户可操作对象，也没有公开 API。
为什么不能用 Go 代码创建或销毁 M
M 是对 OS 线程（如 Linux 的 pthread）的封装，其生命周期由 runtime 内部调度逻辑严格控制。所有 M 的创建都发生在底层 C 代码（newm）和汇编 glue 中，Go 层面连 runtime.NewM 这样的函数都不存在。
- 调用
runtime.LockOSThread()不会“创建 M”，而是可能触发 runtime 新建一个 M 来满足独占绑定需求 -
runtime.GOMAXPROCS()只影响 P 数量，对 M 的上限无硬约束（实际软上限约 10000，但阻塞场景下极易突破） - 试图用
unsafe或反射操作m结构体是未定义行为，m在不同 Go 版本中字段不兼容且无 ABI 保证
哪些场景会触发 runtime 创建新 M
runtime 创建 M 的动机只有一个：让就绪的 G 能立刻运行，而不是等待已有 M 解除阻塞。常见触发点包括：
- 所有当前 M 都被系统调用阻塞（如
read、accept、epoll_wait），而本地 P 队列还有 G 待执行 - 程序启动时初始化调度器，预创建少量 M（通常 1~2 个）配合默认 P 启动循环
- cgo 调用中从 C 线程回调 Go 函数时，runtime 会为该 C 线程分配一个专属 M（即 g0 所在的 M）
- 某个 M 因信号处理、栈切换异常或调试器介入导致状态不可恢复，runtime 用新 M 接管其 P 和待运行 G
注意：newm 开销不小——涉及 clone() 系统调用、栈内存分配（2MB）、TLS 初始化等，runtime 会优先复用 idle M。
M 的“销毁”其实是休眠 + detach，且条件极苛刻
所谓“销毁”只是将 M 置为 idle 并调用 pthread_detach() 归还线程资源，前提是同时满足：
- 未绑定
runtime.LockOSThread()（绑定后永不回收） - 已解绑 P，且 handoffp 完成（P 已移交或进入自旋）
- 不在系统调用中（比如没卡在
read()或nanosleep()） - 本地 P 队列为空、全局队列也无待运行 G
- 连续空闲超阈值（实测通常需 2 秒以上，非 10ms；10ms 是更早的 idle 标记阈值，非释放阈值）
HTTP 长连接、DB 连接池空闲等待、裸 time.Sleep() 循环，都会让 M 停留在“可运行但无 G”状态，永远不满足回收条件。
cgo 派生的 M 为何永不被 runtime 回收
cgo 场景下的 M 完全脱离 runtime 调度路径：
- 它不绑定 P，也不参与 work stealing 或 handoffp
- runtime 不知道它何时结束，不会主动调用
pthread_detach() - C 侧若长期不返回（如阻塞在
poll()），或忘记调用runtime.Goexit()，该 M 就一直驻留 - 典型泄漏模式：
go C.some_blocking_call()后无超时，ps -T 可见线程数只增不减
真正容易被忽略的是：M 与 OS 线程 ID 并非永久绑定。strace 中看到相同 tid 多次出现，不代表回收失效——那是 runtime 复用 idle M 的正常表现。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
