Go调度器不自动检测协程饥饿，需结合pprof block profile（查阻塞）、主动调度点（如runtime.Gosched或time.Sleep）、时间戳日志及context超时等手段综合定位。
Go 调度器本身不提供协程饥饿的自动检测能力，必须靠外部可观测性手段定位——runtime.NumGoroutine() 只能看数量，真正要确认“某个 goroutine 长期没被调度”，得结合 pprof block profile 和自定义时间戳日志。
用 pprof block profile 捕获阻塞型饥饿
block profile 记录的是 goroutine 等待锁、channel、syscall 等资源的时间，不是 CPU 占用时间。当某个 goroutine 因 select 持续选中其他 case 而长期得不到执行时，它不会出现在 block profile 里（因为它根本没阻塞），但它的上游 channel 可能因无人消费而堆积，进而导致写端 goroutine 在 ch <- x 处 block ——这时 block profile 就能暴露问题。
- 启动时开启：
runtime.SetBlockProfileRate(1)（1 表示每发生 1 次阻塞就采样） - 运行一段时间后访问
/debug/pprof/block，重点关注sync.runtime_SemacquireMutex或runtime.chansend1的调用栈 - 若发现某条路径下
ch <-占比极高且持续增长，说明对应读端 goroutine 可能被饿死或卡住
对计算密集型任务加主动调度点
纯算术循环或原子操作（如 atomic.AddUint64）不触发调度点，runtime.Gosched() 不是万能解药，但它是唯一能在 tight loop 中插入协作点的手段。关键不是“要不要加”，而是“加在哪”和“加多频繁”。
- 不要在每轮循环都调用
runtime.Gosched()：这等于手动制造高频上下文切换，反而增加抖动 - 推荐每处理 1000–10000 个单位后调用一次，例如：
if i%5000 == 0 { runtime.Gosched() } - 更优替代：
time.Sleep(1 * time.Nanosecond)，语义明确（真暂停）、兼容性好、新版 Go 中调度器对其处理更稳定 - 务必确认该循环中无未完成的临界区操作，比如刚更新完共享变量还没 flush 到内存，就 Gosched，其他 goroutine 可能读到脏数据
用时间戳日志识别逻辑层饥饿
很多“饥饿”不是调度器问题，而是业务逻辑卡在某处没推进。比如一个健康检查 goroutine 每 5 秒发一次请求，但日志显示它连续 30 秒没打印任何输出——这不是调度器不给时间片，而是它卡在了某次超时未设的 http.Get 上。
立即学习“go语言免费学习笔记（深入）”；
- 在关键路径入口打带时间戳的日志，例如：
log.Printf("[health] start at %v", time.Now()) - 避免只打 “start” 和 “done”，中间加 “waiting for X”、“got Y” 等中间状态，便于定位卡点
- 对定时任务，用
time.AfterFunc替代裸time.Sleep+for循环，防止一次卡住整个循环体 - 所有 I/O 操作必须带 context 超时：
http.DefaultClient.Do(req.WithContext(ctx))，否则单次 hang 就拖垮整条链路
真正难排查的饥饿，往往藏在“看似正常”的地方：一个没设超时的 select 等待、一个被缓冲区撑满却无人消费的 channel、一段内联后消失的函数调用边界。检测本身不难，难的是把观测点布设到这些沉默的角落。
