Go调度依赖G-M-P协作、工作窃取和抢占机制实现动态平衡，并非自动公平；新goroutine可能延迟执行因入本地/全局队列，长循环卡P因缺乏安全点，负载不均导致饥饿，需用schedtrace或trace工具观测真实行为。
Goroutine 调度不是“自动就公平”，而是靠 G-M-P 三者协作 + 工作窃取 + 抢占机制共同维持的动态平衡。 它不依赖操作系统调度器，而是在用户态由 Go runtime 自主管理，核心目标是：用少量 OS 线程（M）高效跑起成千上万个 Goroutine（G），同时不让任何一个 G 长时间霸占 CPU。
为什么新 go 启动的 Goroutine 不一定立刻执行？
刚调用 go f() 时，runtime 并不会马上分配线程去跑它，而是先把它放进某个 P 的本地队列（若该 P 有空位），或全局队列（global runq）——这取决于当前所有 P 的本地队列是否已满（每个最多存 256 个）。只有当某个 M 绑定的 P 在调度循环中发现本地队列非空，才会取出一个 G 执行。
- 如果所有
P的本地队列都满了，新G会进全局队列，但访问全局队列需加锁，开销大，所以 runtime 会尽量避免 -
GOMAXPROCS决定了P的数量（默认 = CPU 核数），也间接决定了“最多有多少个G可并行尝试执行” - 哪怕只启动 1 个
G，也可能因P正忙于其他任务、或M被系统调用阻塞而延迟调度
为什么长时间运行的 for 循环会卡住整个 P？
Go 1.14 前是协作式调度：Goroutine 必须在“安全点”（如函数调用、垃圾回收检查点、channel 操作）主动让出控制权。一个纯计算型 for 循环若不含函数调用（尤其被编译器内联后），就不会触发调度检查，导致绑定的 M 和 P 被独占 —— 其他 G 在该 P 上永远排不上队。
- Go 1.14+ 引入异步抢占：后台线程
sysmon每 10ms 检查一次各P的schedtick是否停滞；若发现某G占用过久，会在其栈上设抢占标记 - 但该标记只在下一次**非内联函数调用**时被检测并触发切换 —— 所以死循环 + 内联函数 +
GOMAXPROCS=1仍可能彻底夯住 - 实操建议：对长耗时计算，显式插入
runtime.Gosched()或拆成小块，避免触发调度盲区
为什么有些 Goroutine 明明没阻塞，却迟迟得不到执行？
这不是调度器“忘了它”，而是典型的负载不均或窃取失败。比如：一个 P1 的本地队列堆了 1000 个 G，而 P2 空闲，但 P2 的 M 在尝试“偷取”时只拿到一半（即 500 个），接着 P1 又快速生成了新 G，导致 P2 再次空转，而 P1 队尾的 G 还在排队。
立即学习“go语言免费学习笔记（深入）”；
- 工作窃取（work-stealing）只发生在本地队列为空时，且每次只偷一半，无法完全消除积压
- 网络 I/O 就绪的
G由netpoller直接放回全局队列，不经过本地队列，可能造成“冷热不均” - 避免方式：控制单个
P上的任务粒度（例如不要一次性 spawn 几千个 goroutine 做同一件事），合理使用runtime.LockOSThread()需谨慎，它会把G和M绑死，破坏调度灵活性
如何观察真实调度行为，而不是猜？
别靠 fmt.Println 或 sleep 推断执行顺序 —— 那只是表象。真要验证调度逻辑，得看运行时暴露的底层信号：
- 用
runtime.NumGoroutine()查数量，但无法反映分布 - 开启调度跟踪：
GODEBUG=schedtrace=1000 ./your-program，每秒输出各P的状态（idle / running / gcwaiting 等） - 生成 trace 文件：
go tool trace，可视化查看每个G的创建、就绪、运行、阻塞时间线 - 注意：
GOMAXPROCS设为 1 时，所有G强制串行，此时看到的“顺序执行”不是调度器功劳，而是人为限制
真正难的从来不是“怎么写 goroutine”，而是理解它何时会被挂起、谁在偷任务、为什么那个 G 总在队尾 —— 这些细节藏在 sysmon 的循环里、runqget 的窃取逻辑中、以及你没写的那行 runtime.Gosched() 里。
