g 不绑定 m，m 也不固定属于 p；但运行中的 g 必须在 m 上执行，每个 m 必须持有且仅持有 1 个 p 才能执行用户代码，这是调度成立的最小契约。
Go 调度器里 G、M、P 到底谁绑谁？
G 不绑定 M，M 也不固定属于某个 P；但每个运行中的 G 必须在某个 M 上执行，而每个 M 又必须持有且仅持有 1 个 P 才能执行用户代码。这是调度得以成立的最小契约。
常见错误是以为 G 启动后就“属于”某个 M —— 实际上一旦 G 进入阻塞（比如系统调用、channel 等待），M 就会与它解绑，甚至可能被回收，而 G 会挂在等待队列里，等条件满足后再由任意空闲 M + P 组合来唤醒。
-
G创建开销极小（2KB 栈），可轻松起数万；M是 OS 线程，创建/销毁代价高，所以运行时会复用M - 当
M进入系统调用时，若该M持有的P还有可运行的G，运行时会尝试“偷”一个新M来接管这个P，避免P空转 - 如果所有
P都满载且无空闲M，而又有新系统调用发生，运行时才会新建M（上限默认为GOMAXPROCS× 限制倍数，实际受runtime.SetMaxThreads约束）
为什么 runtime.LockOSThread() 会让 G 和 M “看起来”绑死了？
它不改变调度模型本质，只是让当前 G 所在的 M 不再被调度器抢占或回收，并禁止该 M 去执行其他 G。此时 M 变成“独占线程”，P 仍归属它，但其他 G 无法再被分配到这个 M 上。
典型使用场景是调用某些 C 库（如 OpenGL、alsa）要求线程局部状态，或需要 pthread_setspecific 类语义。但副作用明显：
立即学习“go语言免费学习笔记（深入）”；
- 该
M无法参与调度平衡，可能导致其他P饥饿 - 若该
G长时间阻塞（比如等用户输入），整个M+P就卡死，浪费并发资源 - 必须配对调用
runtime.UnlockOSThread()，否则泄漏会逐步耗尽可用M
goroutine 阻塞时，P 怎么不丢？
关键在“M 可以丢，P 不能丢”。当 G 因 channel receive、network I/O、time.Sleep 等进入阻塞，运行时会把 G 推入对应等待队列（如 sudog 链表），然后让当前 M 执行 schedule() 函数——此时若该 M 没有其他可运行 G，它就会尝试释放持有的 P，并进入休眠（转入 findrunnable() 循环等待新任务）。
而 P 不会被销毁，而是回到全局空闲队列（allp 数组中未被占用的 slot），或被其他唤醒的 M 直接获取。这也是为什么 goroutine 大量阻塞时，CPU 使用率仍可控：空闲 P 不会主动拉起新 M，除非有新可运行 G 到达。
- 系统调用阻塞（如
read()）走的是另一条路径：M会脱离P单独阻塞，同时运行时尝试用其他M接管该P - 非阻塞系统调用（如
epoll_wait）由 netpoller 统一管理，G直接挂起，M立即回归调度循环 -
select语句中的多个 channel 操作，会被编译为对sudog的批量注册/注销，不依赖单个M生命周期
G-M-P 模型下，哪些操作真会影响调度性能？
不是所有“看起来重”的操作都伤调度。真正拖慢整体吞吐的，是那些让 P 长期无法切换 G、或频繁触发 M 创建/回收的动作。
- 在
for循环里密集调用runtime.Gosched()：人为让出P，但没释放 CPU，反而增加调度器负担 - 大量短生命周期 goroutine + 频繁 channel 通信：导致
sudog分配/回收和锁竞争上升（尤其在 contended channel 场景） - 滥用
sync.Pool存储大对象：虽减少 GC，但若对象内含指针且生命周期跨G，可能延长P的 STW 时间 - 设置
GOMAXPROCS远超物理核数：不会提升吞吐，反而因上下文切换增多、cache 局部性变差而降低性能
最常被忽略的一点：CGO 调用期间，该 M 完全脱离 Go 调度器视野，既不计为“空闲”，也不参与 steal，更不会响应 GOMAXPROCS 动态调整 —— 它就像一个黑盒线程，直到返回 Go 代码才重新纳入管理。
