gmp调度模型不提供应用层负载均衡，p数量由gomaxprocs控制，仅决定单机并行执行g的最大能力，而非跨服务请求分发；工作窃取仅限就绪态g的本地调度，对i/o阻塞、channel等待、锁竞争等场景无效。
Go 的 GMP 调度模型本身不提供“应用层负载均衡”，它解决的是运行时层面的 Goroutine 分发与执行效率问题；想靠改 GOMAXPROCS 或调 runtime.Gosched() 来做服务级负载均衡，是方向性错误。
为什么 P 的数量 ≠ 并发任务的负载均衡开关？
GOMAXPROCS 控制的是逻辑处理器 P 的最大数量，默认等于 CPU 核心数。它影响的是“最多有多少个 M 可以并行执行 G”，而非“请求该往哪台机器、哪个 goroutine 分发”。P 是单机调度单元，不跨进程、不跨网络。
- 设
GOMAXPROCS=1：所有 Goroutine 串行跑在单个 P 上，M 频繁切换 G，但 CPU 利用率低、吞吐受限 - 设
GOMAXPROCS=64（远超物理核）：P 数量过多导致 M-P 绑定开销上升、本地队列变短、工作窃取更频繁，反而增加调度抖动 - 真实瓶颈常在 I/O、锁竞争或 channel 阻塞上，不是 P 数不够——此时加 P 毫无帮助
工作窃取（Work Stealing）不是“自动均摊请求”的魔法
当某个 P 的本地队列（LRQ）为空时，它会从其他 P 的 LRQ 尾部偷一半 G 来执行。这仅发生在同一进程内、且仅针对就绪态 G（_Grunnable），对以下情况完全无效：
- 正在系统调用中阻塞的 G（如
net.Conn.Read）：它们不在任何 LRQ 或 GRQ 中，而是挂在 netpoller 上 - 因 channel 发送/接收而阻塞的 G：它们进入 channel 自己的等待队列，不参与窃取
- 被 mutex 或
sync.WaitGroup卡住的 G：它们处于_Gwaiting状态，调度器不主动挪动
也就是说，你写了个死锁的 channel 操作，再多 P 和再勤快的窃取也救不了它。
学习 GMP 时最容易忽略的底层细节
初学者常把 GMP 当成“类线程池”来理解，但实际机制更精细也更隐蔽：
-
sysmon线程每 20–100ms 扫描一次，发现运行超 10ms 的 G 就插入抢占标记；但这个抢占只在函数调用返回点生效，不会中断 for 循环里的纯计算——所以写长循环必须手动插runtime.Gosched() - P 的本地队列容量固定为 256，满后新 G 会批量迁移到全局队列（GRQ）；而 GRQ 是全局锁保护的，高并发创建 G 时这里会成为瓶颈
- M 在系统调用阻塞时会与 P 解绑，但解绑前会把 LRQ 剩余 G 转交其他空闲 M；若没有空闲 M，这些 G 就卡在 LRQ 直到 M 回来——这就是为什么
net/http默认用协程处理连接，却仍可能因 syscall 阻塞堆积
真正影响高并发表现的，往往不是 GMP 模型本身是否“高级”，而是你有没有意识到：G 的阻塞状态分类、P 的队列边界、M 的生命周期，全由 Go 运行时静默管理——你看不见它们，但它们随时在决定你的程序卡在哪。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
