pprof block profile 无法直接显示协程饥饿，但可通过 Runnable 状态持续不转为 Running、mutex contention 高、RWMutex 漏 RUnlock 导致 writerSem 永久阻塞等间接迹象定位饥饿根源。
pprof block profile 看不到饥饿，但能间接暴露写端阻塞
协程“饿死”本身不会出现在 block profile 里——它没阻塞，只是永远抢不到锁。真正会被捕获的是它的**副作用**：比如写端 goroutine 在 ch 处持续阻塞，因为读端被饿死、无人消费 channel。
启动时加一句：runtime.SetBlockProfileRate(1)，跑一段时间后访问 /debug/pprof/block，重点关注调用栈中：
-
runtime.chansend1出现频次高且堆栈固定（尤其在某个 handler 或 worker 内） -
sync.runtime_SemacquireMutex下方有明显长链，且锁对象地址重复出现 - 同一 mutex 的阻塞总纳秒数持续增长，而非偶发尖峰
这说明不是“偶尔慢”，而是某条路径长期卡在锁或 channel 上。
用 go tool trace 观察 goroutine 调度延迟
go tool trace 是少数能直接看到“本该运行却没运行”的工具。它记录每个 goroutine 的状态切换，包括 Runnable → Running 的延迟。
关键操作步骤：
- 启动程序前加
trace.Start(os.Stderr)，运行几秒后trace.Stop() - 导出 trace 文件：
go tool trace -http=:8080 trace.out - 打开浏览器，点「Goroutine analysis」→「Longest running goroutines」，看是否有 goroutine 的
Runnable时间远超其他（比如 >10ms） - 点进该 goroutine，看它是否反复处于
Runnable状态但迟迟不进入Running—— 这是典型调度器插队导致的饥饿迹象
注意：这种延迟必须排除 GC STW、系统调用等干扰，重点看连续多个周期都卡在 Runnable 的 goroutine。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
检查 sync.Mutex 是否频繁触发饥饿模式
Go 的 sync.Mutex 在等待超 1ms 后自动切饥饿模式，这不是错误，但它是饥饿已发生的**结果证据**。你可以通过 pprof mutex profile 或日志确认：
- 开启 mutex profile：
runtime.SetMutexProfileFraction(1)，之后访问/debug/pprof/mutex - 若某 mutex 的
contention=值极高（如 >1000），且调用栈集中在同一业务函数，说明争抢激烈 - 更直接的办法：在关键锁附近加日志，用
time.Since(start)记录实际等待时间，若多次 >1ms，说明已进入饥饿模式 - 注意：饥饿模式下新 goroutine 会直接排队到尾部，不再自旋——这意味着你看到的“慢”，其实是公平性让步换来的稳定性
读写锁 sync.RWMutex 的漏解锁比死锁更隐蔽
sync.RWMutex 饥饿常源于 RUnlock() 漏掉，而不是锁本身设计问题。漏一次，readerCount 就永远不归零，后续所有 Lock() 都永久阻塞在 writerSem 上。
排查要点：
- 绝不在
RLock()后直接return，必须用defer mu.RUnlock()包裹，哪怕中间有 error 分支 - 检查 panic 路径：如果
RLock()后调用了可能 panic 的函数（如json.Unmarshal），需用recover+ 显式RUnlock() - 用
go vet -race无法发现漏解锁，但它能提示RUnlock() without matching RLock()类似警告（取决于 Go 版本） - 最稳妥方式：把读锁逻辑封装成函数，入口
RLock()，出口统一RUnlock()，避免裸写
真正难定位的饥饿，往往不是调度器不给时间片，而是锁根本没被释放——它卡在了你没看到的 defer 之外、panic 之中、或提前 return 的分支里。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
