Go 1.14 的抢占式调度到底解决了什么问题
它解决的是 runtime.Gosched() 无法插入、长时间不交出 CPU 的 goroutine 卡死调度器的问题。典型场景就是纯计算密集型循环，比如 for { i++ } 或矩阵遍历，没有函数调用、没有 channel 操作、没有系统调用 —— 这类代码在 1.13 及之前版本里，会让 P 长期绑定 M，其他 goroutine 彻底“饿死”。
1.14 引入基于信号的异步抢占（asynchronous preemption），让运行超过 10ms 的 goroutine 有机会被中断。但注意：这不是实时调度，也不是每 10ms 强制切走，而是依赖协作点（如函数入口、垃圾回收扫描点）+ 信号触发的组合机制。
- 抢占只对运行超时的 goroutine 生效，且必须在有“安全点”（safe point）的位置才能真正挂起
- 纯空循环
for {}在 1.14 中仍可能逃逸抢占（因为没函数调用，无安全点），需手动插入runtime.Gosched()或time.Sleep(0) - 抢占开销极低，但频繁触发说明逻辑设计有问题，不是靠调度器兜底的场景
如何验证你的 goroutine 是否被抢占
不能靠肉眼观察，得看调度器 trace 和 goroutine 状态变化。最直接的方式是开启调度器追踪：
go run -gcflags="-l" -ldflags="-s -w" main.go 2>&1 | GODEBUG=schedtrace=1000 ./main
每秒输出一行调度器快照，关注 SCHED 行中的 g 数和 runq 长度变化；若某个 goroutine 长时间占据 m->curg 且 runq 持续堆积，说明它大概率没被及时抢占。
立即学习“go语言免费学习笔记（深入）”；
- 用
runtime.ReadMemStats()+debug.SetGCPercent(-1)可排除 GC 干扰，聚焦调度行为 -
pprof的goroutineprofile 能看到阻塞在running状态的 goroutine，但无法区分是真计算还是假卡死 - 真实环境慎用
schedtrace，它本身有性能开销，仅用于诊断
密集循环里怎么写才不容易被调度器“放弃”
别指望调度器替你做责任划分。Go 的抢占不是为拯救烂代码而生的，而是为保障基础调度公平性。你要主动给调度器留出口：
- 避免裸
for {}，改用带条件判断的循环，哪怕只是for i := 0; i ，每次迭代都有函数返回点 - 在长循环体内每千次或毫秒级插入
runtime.Gosched()，尤其当循环体不含任何函数调用时 - 用
time.Sleep(0)替代Gosched()也可行，但它会进入网络轮询器，轻微增加延迟，不如前者轻量 - 如果循环本质是等待某状态，优先用
select+time.After或 channel 同步，而非忙等
为什么升级到 1.14+ 后反而出现更多“意外切换”
这不是 bug，是行为收敛。旧版本中你以为“稳定”的执行顺序，其实是调度器无力干预下的偶然结果；1.14 让行为更可预测，但也暴露了原来被掩盖的竞态或时序假设。
- 原本靠“永不切换”实现的单线程假象被打破，共享变量未加锁就可能出错
- 某些测试依赖 goroutine 执行顺序，现在会随机失败 —— 这类测试本身就不符合 Go 的并发模型
- CGO 调用期间无法被抢占（M 进入
g0栈），若 C 函数执行太久，依然会导致调度停滞，这点没变
复杂点在于：抢占边界不透明，安全点由编译器自动插入，你没法精确控制时机。能做的只有承认它存在，并按协作式并发的本来面目去写代码。
