Golang并发程序调试的常用技巧

快速定位 goroutine 泄漏需先用 runtime.NumGoroutine() 监控增长，再通过 pprof/goroutine?debug=2 查看阻塞在 select{}、chan recv 或 sync.WaitGroup.Wait 的栈；常见原因包括漏调 wg.Done()、向已关闭 channel 发送、for 循环中未 stop time.After 创建的 timer。

goroutine 泄漏怎么快速定位

运行时 goroutine 数量持续增长，通常是泄漏的典型信号。别急着看业务逻辑，先用 runtime.NumGoroutine() 打点日志或暴露 HTTP 指标，确认是否真在涨。更直接的是用 pprof：

curl -s http://localhost:6060/debug/pprof/goroutine?debug=2

，加 ?debug=2 能看到完整调用栈，重点找那些卡在 select{}、chan recv 或 sync.WaitGroup.Wait 的 goroutine。

常见陷阱：

• 忘记调用 wg.Done()（尤其在 error 分支里）
• 向已关闭的 channel 发送数据导致永久阻塞
• 使用 time.After 在 for 循环里反复创建 timer，却不 stop

竞态条件（race condition）必须开 -race 编译

Go 的 -race 检测器不是可选项，是并发调试的底线。它会在运行时捕获读写冲突，输出类似这样的报告：

WARNING: DATA RACE
Write at 0x00c00001a080 by goroutine 7:
  main.main.func1()
      /tmp/main.go:12 +0x39
Previous read at 0x0
0c00001a080 by goroutine 6:
  main.main.func2()
      /tmp/main.go:16 +0x52

。注意它只对运行时访问生效，不会检测未执行到的代码路径；而且一旦开启，程序性能下降明显，**仅用于测试环境**。

容易忽略的点：

• struct 字段未加锁，但多个 goroutine 同时读写不同字段——仍可能触发 false positive（因内存对齐重叠）
• map 并发读写必须用 sync.Map 或显式锁，-race 能抓到，但上线后 panic 更常见

channel 死锁 panic 的真实原因

“fatal error: all goroutines are asleep - deadlock” 不一定代表你写了 select {}，而是所有 goroutine 都卡在 channel 操作上且无其他唤醒路径。典型场景：

• 向无缓冲 channel 发送，但没有 goroutine 在接收
• 从已关闭且为空的 channel 接收（会立即返回零值，不阻塞）——这不是死锁，但常被误判
• 用 for range ch 遍历一个永远不会关闭的 channel

调试建议：启动时加 GODEBUG=schedtrace=1000，每秒打印调度器状态，观察 goroutine 是否长期处于 runnable 或 waiting 状态；配合 pprof/goroutine?debug=2 看阻塞点。

调试时慎用 fmt.Println 打印 goroutine ID

fmt.Println 是同步 I/O，本身会抢锁、影响调度，尤其在高并发下可能掩盖或改变竞态行为。想打日志又不想干扰行为，优先用 log 包并设置 log.Lshortfile，或者用 runtime.Caller(1) 获取当前 goroutine 栈帧信息。如果真要区分 goroutine，可以这样轻量标记：

go func(id int) {
    log.Printf("[goroutine %d] started", id)
    // ...
}(i)

，但别用 runtime.Goid()——它不是公开 API，Go 1.22+ 已移除。

真正难缠的问题往往藏在：timer 未 stop、context.WithCancel 后没 cancel、http.Client 的 Transport 复用导致连接池 goroutine 残留——这些不会立刻报错，但压测一阵后资源就悄悄耗尽。