go调度器不靠中心化“分配”任务，而是m主动按优先级从本地队列→全局队列→网络就绪→其他p窃取的去中心化取任务机制；本地队列无锁、高热，全局队列带锁仅作饥饿兜底，网络就绪和窃取为动态触发条件，非静态三级结构。
Go 调度器不靠“分配”任务，而是让 M 主动从队列中“拿”任务；所谓“三级队列”其实是本地队列 + 全局队列 + 网络就绪队列的协同机制，不是静态分层结构。
为什么说“分配”这个词容易误导？
调度器没有中心式任务派发器。每个 M 绑定一个 P 后，自己按固定优先级顺序去取 G：先查 P 的本地队列（runq），空了再查全局队列（GRQ），再空就查网络轮询器（netpoller），最后才去别的 P 那里偷。这个过程是去中心化、无锁（本地队列无锁）、带局部性保障的。
常见错误现象：
– 以为 go func() 创建后立刻被某个特定 M 执行
– 在 pprof 中看到 G 在不同 M 上跳转，误判为“乱调度”
– 把 GOMAXPROCS 当作线程池大小，强行设成远超 CPU 核数的值，反而加剧窃取开销
P 的本地队列（runq）怎么用？
这是最热路径，90% 以上的新建 G 都走这里。它是个长度为 256 的循环数组（runq[256]），支持 O(1) 入队/出队，完全无锁。
- 新
G默认插入当前P的runqtail位置 - 如果
runq满了（runqtail == runqhead），运行时会把一半G迁移到GRQ，再把新G放进本地队列 -
runnext字段是“快通道”：当一个G刚被唤醒（比如 channel 发送完成），会优先塞进runnext，下一次调度直接取它，避免入队再出队的延迟
全局队列（GRQ）什么时候会被访问？
GRQ 是带互斥锁的链表，只在两种场景下被动使用：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
M执行完 61 个G后，强制检查一次GRQ（防止饥饿） -
P的本地队列为空，且netpoller也没就绪G时，才会加锁从GRQ批量取（默认取 1/4，最少 1 个，最多 32 个）
性能影响明显：
– 高并发创建 goroutine 时，若频繁触发 GRQ 插入/取出，会成为锁瓶颈
– runtime.GC 或 sysmon 唤醒的 G 也走 GRQ，所以 GC 峰值期可能拖慢新 G 调度
网络就绪队列和工作窃取怎么配合？
这不是独立队列，而是两个触发条件：
- 每次
M发现本地队列空，第一反应不是马上锁GRQ，而是调用netpoll(false)查看是否有刚完成的网络 I/O（如read就绪、accept返回），有就直接执行 - 仍无任务时，才进入工作窃取：随机选一个其他
P，从它runq尾部偷一半（向下取整）的G，偷不到就继续换下一个P，最多试 4 次
容易踩的坑：
– 窃取失败后 M 会与 P 解绑，进入休眠（park），但唤醒时机依赖 sysmon 或新 G 到达，不是即时响应
– 如果所有 P 的 runq 都极短（比如平均只有 1~2 个 G），窃取成功率低，M 可能频繁休眠/唤醒，增加调度抖动
真正关键的是 P 数量与负载的匹配——不是队列层级多深，而是本地队列是否够热、窃取是否常触发、GRQ 是否成了常态通路。这些信号比“三级队列”的字面描述更能反映调度健康度。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
