热路径延迟大概率是GMP调度卡顿而非CPU瓶颈，应通过go tool pprof -goroutine查_Grunnable/_Gwaiting状态分布，并用go tool trace观察Scheduler页中G的running block时长及全局队列消费情况，结合NumCgoCall等指标定位CGO阻塞或抢占失效问题。
热路径上看到延迟，大概率不是 CPU 瓶颈，而是 GMP 调度卡在了某个环节——比如 P 被独占、G 堆在全局队列、或 M 被回收后唤醒慢。
怎么确认是调度延迟而非业务慢
别靠 time.Now() 差值猜，先看真实状态分布：
- 用
go tool pprof -goroutine查看 goroutine 状态：如果大量 G 卡在_Grunnable（就绪但没执行）或_Gwaiting（等 channel/timer）但 CPU 使用率很低，就是调度层积压 - 运行
go tool trace，打开浏览器后重点看Scheduler标签页：观察单个 G 的runningblock 是否持续超 10ms（说明抢占失效），或多个 G 在runnable状态停留过久（说明队列没被及时消费） - 检查
runtime.ReadMemStats中的NumGoroutine和NumCgoCall：若后者突增且伴随延迟，大概率是 CGO 阻塞触发 M 回收
纯计算循环导致的抢占失效怎么定位
Go 的异步抢占只在安全点生效（函数调用、栈检查、GC 扫描），内联后的死循环根本不会触发。现象是：一个 for { i++ } 吃满一个 P，其他 G 完全饿死。
- 验证方式：在循环里加
runtime.KeepAlive(&i)或println(1)，看输出是否均匀间隔；不加则可能几秒才刷一次 - 编译时加
-gcflags="-l"关闭内联，让函数调用保留在汇编中，可快速恢复抢占点 - 修复不是加
runtime.Gosched()就完事——它只是把 G 放回本地队列尾部，若队列只有它一个，立刻又被取出；得配合分块（如if i%1000 == 0 { runtime.Gosched() }）或插入time.Sleep(0)
新起 goroutine 为什么迟迟不执行
调用 go f() 只是入队，不是立即调度。默认进当前 P 的本地队列（最多 256 个），满了才进全局队列；而调度器每约 61 次调度才强制扫一次全局队列。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 高 QPS HTTP handler 里无节制
go func(){}，会导致大量 G 拥塞在全局队列，新 P（比如扩容后）要空转好几轮才分到任务 - 避免方式：用
sync.Pool复用 goroutine，或走 worker pool 模式，把新建开销和队列依赖降到最低 - 注意
for range中直接捕获循环变量（如go func(){ println(i) }()）输出全是最后一个值——这不是调度问题，是闭包共享变量，但常被误判为“调度不均”
CGO 阻塞后唤醒变慢的根本原因
CGO 函数默认不被 Go 调度器感知。若一个 goroutine 进入 C 的 sleep(5)，而你又没调 runtime.LockOSThread()，M 可能被 sysmon 判定为空闲并回收。C 返回时，M 得重新找 P、抢锁、入队，延迟明显。
- 监控指标：
runtime.NumCgoCall()持续高位 +runtime.NumThread()波动剧烈，基本可锁定 - 修复优先级：能不用 CGO 就不用；必须用时，确保 C 函数内不阻塞太久，或配对使用
runtime.LockOSThread()+runtime.UnlockOSThread() - 别以为
GOMAXPROCS调大就能缓解——P 多了反而加剧 work-stealing 竞争，findrunnable开销上升
真正难排查的是那种“看起来在跑，但响应就是慢”的情况：G 状态是 _Grunning，trace 里 block 时间却远超 10ms，说明抢占点彻底消失——这时候得看汇编、关内联、插 KeepAlive，而不是改业务逻辑。
