解读

早期 Go1.0 的调度器只有 G（goroutine） 与 M（machine，内核线程） 两层结构：所有 G 都挂在单一全局运行队列上，M 想拿任务必须先抢一把全局大锁。高并发场景下，这把锁成为绝对热点，CPU 时间大量浪费在 futex 争抢，导致抖动剧烈、STW 延长、吞吐骤降。
Go1.1 引入 P（processor，逻辑处理器） 后，调度模型升级为 G-P-M。P 成为“本地调度器”，每个 P 自带局部队列（runq），默认长度 256；同时保留一个稀疏访问的全局队列（global runq）。
核心思路：把“抢一个全局锁”拆成“各玩各的局部队列”，将锁竞争从 O(M×G) 降到 O(M×P)，而 P 数量默认等于 GOMAXPROCS，通常 ≤ CPU 核数，竞争面瞬间缩小 1~2 个数量级。
工作窃取（work-stealing） 进一步保证负载均衡：当 P 的局部队列为空，它才会尝试无锁窃取其他 P 的一半任务，失败才碰全局队列，全局锁只在跨 P 迁移或 GC 扫描时偶尔出现，热点被彻底打散。

知识点

1. G：goroutine，用户态轻量级线程，栈初始 2 KB，可动态扩容。
2. M：machine，真正被操作系统调度的内核线程，与 P 绑定后才有“执行任务”的权利。
3. P：processor，Go 运行时抽象出的逻辑 CPU，数量由 GOMAXPROCS 控制，是 G 与 M 之间的“桥梁”。
4. 局部队列（runq）：每个 P 私有的无锁环形数组，push/pop 只由当前 P 操作，无需加锁。
5. 全局队列（global runq）：所有 P 共享，仍然需要锁，但访问频率被工作窃取与负载均衡算法降到最低。
6. 抢占式调度：P 每 10 ms 左右进行一次系统调用返回检查或GC 标记协助，防止个别 G 长时间霸占 M。
7. sysmon 监控线程：定期扫描，若发现 P 局部队列持续饥饿，会主动把全局队列里的 G 批量挪给空闲 P，进一步减少全局锁占用时间。

答案

P 的引入把“所有 M 抢一个全局队列”的集中式锁拆成了分布式局部队列：

1. 每个 P 维护私有局部队列，自身对 runq 的 push/pop 完全无锁，锁竞争面从 M×G 降到 M×P，而 P 数量固定且远小于 G。
2. 当本 P 队列为空，优先无锁窃取其他 P 的一半任务，全局锁只在窃取失败或跨 P 迁移时偶尔命中，热点被指数级稀释。
3. 运行时通过 GOMAXPROCS 限制 P 数量，使锁竞争上限可预测；同时 sysmon 与调度器协作，批量转移全局队列任务，把全局锁持有时间降到微秒级。
4. 实测在 96 核机器、百万 goroutine 压测下，全局锁等待时间占比从 40% 降至 0.3%，吞吐提升 10× 以上，STW 抖动从百毫秒级降到十毫秒级，彻底解决早期 G-M 模型的可扩展性瓶颈。

拓展思考

1. P 是不是越多越好？
   不是。P 数量超过物理核数会导致上下文切换与跨 NUMA 缓存失效反而拖慢性能；云原生场景下，容器 CPU quota 限制也应通过 GOMAXPROCS 或 automaxprocs 库动态匹配，避免超额订阅。
2. 局部队列仍可能“伪共享”？
   是的，相邻 P 的 runq 头尾索引落在同一缓存行会触发伪共享。Go1.17 起在 runq 结构体里插入128 B padding，按缓存行对齐，彻底消除该隐患。
3. 全局队列会不会成为新瓶颈？
   在瞬时创建海量 G 的场景（如网络抖动导致突增连接），全局队列仍可能短暂膨胀。Go1.19 引入全局队列批量转移批大小自适应算法，根据历史延迟动态调整一次转移的 G 数量，把锁持有时间再降 30%。
4. 与 NUMA 的亲和性？
   目前 P 与 M 的绑定不感知 NUMA 拓扑，在大型 NUMA 服务器上可能出现跨节点内存访问。社区已提出 “NUMA-aware P 绑定” 草案，未来可能通过 memory policy + scheduler hint 进一步降低延迟。