Go 的 GMP 模型是为解决调度瓶颈逐步演进的工程方案，核心是让海量 Goroutine 在多核上高效并行：1.0 的 GM 模型因全局队列锁竞争和系统调用阻塞导致单核瓶颈；1.1 引入 P 实现本地队列、work-stealing 和 M-P 解绑；GOMAXPROCS 非并发开关而是调度杠杆；1.14 起采用信号抢占提升公平性但 syscall 中仍不可中断。
Go 语言的 MPG（更准确应称 GMP）模型不是一上来就设计好的，而是为解决真实调度瓶颈逐步迭代出来的。它本质是一套“用软件抽象绕过操作系统限制”的工程方案，核心目标始终是：让 go 关键字启动的成千上万个 G 能在多核机器上真正跑起来，而不是卡在锁、系统调用或缓存失效上。
为什么 Go 1.0 的 GM 模型在 8 核机器上只能打满 1 个核？
因为所有 G 都挤在同一个全局队列里，所有 M（OS 线程）必须抢同一把锁才能取任务——runtime.runqget 和 runtime.runqput 成为性能热点。实测中，14% 的 CPU 时间花在锁竞争上；更糟的是，只要一个 M 进入阻塞系统调用（比如 read），它上面所有待运行的 G 就全被挂起，其他 M 却抢不到新任务，导致大量核心闲置。
常见错误现象包括：
- 高并发压测时 CPU 利用率始终无法突破单核上限
-
pprof显示runtime.lock占用显著 - 大量
G处于runnable状态但长期得不到执行
Go 1.1 引入 P 后，GMP 如何实际降低锁争用？
P 不是线程，也不是 CPU 核心，而是一组调度上下文资源包：本地队列 runq（长度 256）、空闲 G 池 gFree、定时器堆、网络轮询器关联等。它的存在让每个 M “自带弹药”，不再依赖全局队列。
立即学习“go语言免费学习笔记（深入）”；
关键机制有：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 新
G默认入当前P的runq，满才进全局队列 -
M执行完一个G后，优先从自己P的runq取下一个，不碰锁 - 当
P.runq空了，M先查全局队列，再尝试从其他P的runq“偷”一半（work-stealing） - 系统调用阻塞时，
M与P解绑（handoffp），空闲M可立即接手该P
runtime.GOMAXPROCS(n) 调大一定能提升吞吐吗？
不能。调大 GOMAXPROCS 只是增加 P 数量，默认等于 CPU 核心数，但它不是并发上限开关，而是调度器平衡“局部性”和“负载扩散”的杠杆。
影响取决于场景：
- 纯 CPU 密集型任务：调大反而可能因跨
P窃取、cache line 无效增多而降低效率 - IO 密集型（尤其带阻塞系统调用）：适当调大可缓解
P饥饿，避免部分M长期空转 -
P数量超过物理核心数后，OS 线程调度开销会上升，需结合top和go tool trace观察实际 M 切换频率
容易忽略的一点是：P 的数量不决定你能创建多少 G（G 数量只受内存限制），也不等于并行度——并行度由活跃的 M-P 绑定对数量决定，而活跃 M 数又受系统线程资源和 GC 停顿影响。
抢占式调度从 1.12 到 1.14 的关键变化是什么？
1.12–1.13 使用基于协作的抢占：编译器在函数调用前插入检查点，若发现抢占请求（如 GC 触发），则让出控制权。问题在于长循环或无函数调用的 CPU 密集代码无法被中断。
1.14 开始改用基于信号的抢占：
- 向长时间运行的
M发送SIGURG信号 - 利用异步安全的信号处理机制强制中断当前
G并调度下一个 - GC 在扫描栈时也触发抢占，覆盖更多边缘场景
但这仍不是完全公平的抢占——例如处于 syscall 中的 G 无法被信号中断，直到返回用户态。所以“防止单个 G 饿死其他 G”的目标，在 1.14+ 已大幅改善，但未彻底闭环。
