热路径调度饥饿表现为纯计算goroutine长期独占M导致同P其他goroutine无法调度；Go异步抢占需安全点且非万能；应手动插入runtime.Gosched()等协作点防饥饿。
goroutine 热路径调度饥饿的真实表现
当一段纯计算逻辑（比如密集循环、数值积分、哈希扫描）在单个 goroutine 中持续运行，且不触发任何函数调用、channel 操作、I/O 或 runtime.Gosched() 时，它可能长期独占绑定的 M（OS 线程），导致同 P 下其他就绪 goroutine 无法被调度——这就是“热路径调度饥饿”。现象包括：pprof 显示某 goroutine 占用 CPU 接近 100%，go tool trace 中看到大量 G 处于 Runnable 状态却迟迟不 Running，而 goroutine profile 里堆积大量处于 running 的栈帧（无阻塞点）。
Go 1.14+ 异步抢占不是全自动开关
异步抢占依赖两个前提：sysmon 定期检查（默认每 10ms）+ 当前 goroutine 执行位置是“安全点”（safe point）。但安全点不是无处不在。以下情况仍可能绕过抢占：
- 纯
for {}循环体中无任何函数调用（包括空函数）、无栈增长触发点、无内存分配 - 内联深度过大，导致编译器未在循环头部插入
runtime.preemptM检查 - CGO 调用期间，抢占信号被屏蔽（
runtime.sigmask阻断） - GC STW 阶段或调度器关键临界区，抢占被临时禁用
也就是说，GOEXPERIMENT=asyncpreemptoff 是关闭开关，但默认开启 ≠ 绝对可靠。不能把它当作“防饥饿银弹”。
手动注入协作点的实操方式
最可控、最轻量、生产环境验证有效的做法，是在热循环中主动插入调度提示。不是加 time.Sleep(0)（开销大），而是用更廉价的原语：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每 N 次迭代调用一次
runtime.Gosched()（N 取 1e4–1e5，避免过度让渡） - 用
atomic.LoadUint64(&counter)替代纯本地变量计数（触发内存屏障 + 编译器不优化掉） - 在循环体开头插入一个空函数调用：
func(){}()—— Go 编译器会为其生成morestack检查，成为抢占安全点 - 若已有日志/指标埋点，把
prometheus.Counter.Inc()或log.Debug()放在循环内（前提是它们本身不阻塞）
示例：
func cpuIntensive(n int) {
var sum int64
for i := 0; i < n; i++ {
sum += int64(i * i)
if i%10000 == 0 {
runtime.Gosched() // 每万次让出一次
}
}
}为什么不要依赖 GOMAXPROCS 调整来“缓解”饥饿
增大 GOMAXPROCS 并不能解决单个 P 内的调度饥饿。因为：
- 饥饿发生在 P 内部的本地运行队列（LRQ）和当前正在执行的 G 之间，与 P 数量无关
- 即使有多个 P，只要某个 P 上的 goroutine 不 yield，该 P 的其他 G 就只能等它完成或被抢占
- 盲目调高
GOMAXPROCS可能加剧上下文切换开销、增加 cache miss，反而降低吞吐
真正影响公平性的，是抢占是否生效、协作点是否足够密、以及是否存在隐式阻塞（如未设 timeout 的 http.Client 导致 goroutine 卡在 netpoller 上假“运行中”）。
热路径的防饥饿，本质是平衡“计算密度”和“调度可见性”。现代 Go 运行时帮你挡掉了大部分边界 case，但最内层那个 for 循环，永远是你自己要负责加呼吸口的地方。
