M必须绑定P才能执行Go代码，因P提供本地队列、mcache等调度上下文；M脱离P后仅能执行runtime调度逻辑或休眠，无法运行用户G。
M 是操作系统线程的抽象封装，不是线程本身，但绑定后等效于一个可执行的内核线程。 它负责真正运行 Goroutine，但必须持有 P 才能执行 Go 代码；一旦 G 进入系统调用阻塞，M 就会释放 P 并休眠——这是理解 M 行为的关键前提。
为什么 M 不能脱离 P 运行用户 Go 代码
M 的设计目标是复用和隔离：它需要 P 提供调度上下文（如本地运行队列 runq、mcache、g0 栈等）。没有 P，M 就像没驾照的司机——能点火（执行汇编 stub），但无法合法调度任何 G。
-
m.g0是 M 的调度栈，所有 runtime 调度逻辑（如schedule()、park_m()）都在这个栈上执行，而非普通 G 的栈 - 当 M 从系统调用返回时，必须先抢到一个空闲 P（通过
acquirep()），否则只能挂起等待，不会直接执行 G -
m.p字段为 nil 时，M 处于“无主”状态，此时它可能正在执行 GC、sysmon 监控，或等待被唤醒分配 P
m 结构体里哪些字段最常影响调试和性能
看 src/runtime/runtime2.go 中的 m 定义，以下字段在分析卡顿、死锁、线程暴涨时最值得关注：
-
m.curg：当前正在运行的 G。若长期不变化且m.p != nil，大概率是该 G 在做 CPU 密集型工作或陷入死循环 -
m.lockedg：非零表示该 M 被LockOSThread()绑定，G 与 M 强绑定，无法被调度器迁移——常见于 CGO 场景，也是 goroutine 泄漏的高发点 -
m.nextwaitm和m.waitnext：用于 sysmon 或 GC 创建的临时 M 链表，若链表过长，说明有大量 M 因阻塞未被及时回收 -
m.spinning：表示该 M 正在自旋尝试获取 P。持续 spinning 但拿不到 P，往往意味着 P 数量不足（GOMAXPROCS设置过低）或 P 被长时间占用（如长时间 GC STW）
什么时候会创建新 M？以及为什么不能无限创建
Go 运行时只在明确需要时才新建 M，主要触发点有三个：
立即学习“go语言免费学习笔记（深入）”；
- 已有 M 全部阻塞（比如都在 syscall 中），但全局运行队列或某个 P 的
runq非空，此时调用newm()启动新线程抢 P - sysmon 监控线程发现有长时间阻塞的 M（超过 10ms），会唤醒一个 idle M 去检查是否需抢占或回收
- GC 的 mark termination 阶段，可能启动额外 M 协助扫描栈（
startTheWorldWithSema）
但 M 不会无限增长：runtime.MemStats.MCacheInuse 和 MCacheSys 可间接反映活跃 M 数量；而实际限制来自 allm 全局链表的锁竞争和 OS 线程创建开销——Linux 下单进程默认线程数上限是 1024，超限会直接 throw("thread create failed")。
真正容易被忽略的是：M 的生命周期不由用户控制，go 关键字不创建 M，runtime.LockOSThread() 才可能让 M “滞留”。排查线程暴涨，优先查 CGO 调用、LockOSThread 漏洞、以及阻塞型 syscall 是否缺少超时控制。
