pprof 数据到底怎么用：Go 为什么要沿三条线把 goroutine 泄漏钉回代码
pprof 抓回来了，最容易发生的事不是你看不懂。
而是你看懂了一半：知道一批 goroutine 卡在 main.worker，知道等待状态是 [chan receive]，知道创建点也在栈里，可下一步还是开始全局搜 context、搜 …
27
5月
6
篇文章
相关文章
共 6 篇
27
5月
goroutine 为什么不能靠猜：Go 排查第一步要先用 NumGoroutine 和 pprof 采样
线上 goroutine 数开始往上爬，很多人的第一反应是猜。
是不是 context 泄漏？是不是超时没生效？是不是某个 channel 没人读？是不是锁没释放？
这些猜法都可能对。
但问题在于，你现在还没有证据。你只有一个数字 …
26
5月
WithTimeout 的 cancel，不是你想象的那个“超时按钮”
接口已经超时了，goroutine 曲线还在往上爬。
上篇讲到这里时，我们先压住了一个误判：这通常不是 context 没生效，而是你的 goroutine 没有响应取消信号。
但还有一个更隐蔽的问题，很多 Go 代码每天都在写：
|
25
5月
超时到了，goroutine 还在涨：context 到底背不背这个锅？
接口超时了，goroutine 曲线还在往上爬。
日志里已经打出 context deadline exceeded，调用方也早就不等了。你盯着监控看了十分钟，心里开始冒出那个判断：是不是 context.WithTimeout 没生效？ …
25
5月
channel 最容易翻车的不是发送接收，而是 close
上一篇讲到最后，其实只把问题说完了一半。
如果你面对的是任务、结果、信号和访问权交接，channel 确实比 mutex 更顺手。它能把 goroutine 之间的关系写出来，让代码不只是在“保护状态”，而是在表达一段通信。
但很多 …
21
5月
Go 服务 goroutine 涨了，别先猜：按这条流程查 context 泄漏
线上 goroutine 数开始往上爬，最怕的不是它涨。
最怕的是你盯着监控看了十分钟，然后开始猜：是不是 context 泄漏了？是不是超时没生效？是不是某个 channel 卡住了？
这些猜法都有可能对，也都有可能错。 …