GM模型撑不住多核，因其依赖单一全局队列导致锁竞争严重、系统调用阻塞整个M、无本地缓存与负载不均；GMP通过引入P实现本地队列、工作窃取和M-P解耦，显著提升多核利用率。
Go 1.0 的 GM 模型在多核机器上根本跑不满 CPU，锁竞争严重，系统调用还会卡住整个线程——这不是设计缺陷，是历史阶段产物；1.1 引入 P 后，GMP 才真正支撑起高并发场景。
GM 模型为什么撑不住多核？
早期 Go（1.0 及之前）只有 G（goroutine）和 M（OS 线程）两个角色，所有 G 都挤在全局队列里，M 必须抢同一把锁才能取 G 执行：
-
GlobalRunQueue是单点瓶颈，尤其在高并发 goroutine 创建/唤醒时，runtime.runqget和runtime.runqput争抢激烈 - M 执行系统调用（比如
read、accept）时会脱离调度器控制，导致该 M 上所有待运行的 G 都被“冻结” - 没有本地队列，M 每次都要去全局队列拿 G，缓存局部性差，频繁跨 cache line 访问
- 无法绑定 CPU 核心，负载天然不均衡，4 核机器可能 3 个 M 堵在锁上，1 个 M 在狂跑
GMP 中 P 的核心作用不是“加一层”，而是解耦+缓存+窃取
P 不是物理 CPU，也不是线程，而是一组调度上下文资源：本地队列 runq、gFree 池、timer 堆、netpoll 关联等。它让 M 能“自带弹药包”干活：
- M 必须绑定一个 P 才能执行 G；P 数量默认 =
runtime.GOMAXPROCS(0)（即 CPU 核心数），可显式调用runtime.GOMAXPROCS(n)修改 - 新创建的 G 优先入当前 P 的
runq（长度 256），满才进global runq；这大幅降低锁争用 - 当 M 发现自己 P 的
runq空了，先查global runq，再尝试从其他 P 的runq“偷”一半（work-stealing），避免空转 - 系统调用阻塞时，M 会与 P 解绑（
handoffp），让另一个空闲 M 接手该 P，原 G 继续留在 P 的队列或runnext中等待唤醒
为什么不能只增加 M 数量来弥补 GM 缺陷？
单纯堆 M（线程）只会让问题更糟：
- 每个 M 都要竞争全局队列锁，M 越多，锁冲突越剧烈，
runtime.lock成为性能热点 - OS 线程创建/切换成本远高于 goroutine，10K 个 M 对系统是灾难，而 10K 个 G 在 P 的本地队列管理下很轻松
- 没有 P 的缓存和窃取机制，大量 M 会同时陷入“取不到 G → 自旋 or 休眠 → 唤醒 → 再抢锁”循环，CPU 白耗在调度上
- Go 1.0 实测：8 核机器上，即使启动 1000 个 goroutine，
top显示 CPU 利用率常卡在 100% 单核，其余核心闲置
真正容易被忽略的是：P 的数量不等于并发上限，也不等于并行度上限；它只是调度器平衡“局部性”和“负载扩散”的杠杆。调大 GOMAXPROCS 可能缓解某些 IO 密集场景的饥饿，但若业务本身是 CPU 密集且无阻塞点，盲目加 P 反而增加窃取开销和 cache miss。观察 runtime.ReadMemStats 中的 NumGoroutine、NumCgoCall 和 /debug/pprof/goroutine?debug=2 的阻塞栈，比调参数更重要。
