突发 Go 协程泄露？还有一招现场诊断

协程泄露是 go 老生常谈的一个问题了。对于这种问题，光看代码的话，如果不能在十分钟内找到怀疑的地方，那基本再花更多时间也是干瞪眼。

还是需要收集更多信息，而且打日志大法还不好用。目前网上的文章，几乎千篇一律，都是用 pprof 工具来进行排查。pprof 工具确实强大，但在我的实践中，发现还是有几点不满意：

1. 需要对代码做侵入式改造
2. 需要重启服务，丢失现场，需要等问题复现

第一点，其实还好。第二点就很耽误事情了，要是问题是在某个特殊情况下触发的，那等问题复现就不知道是什么时候了。当然一直开启 pprof 也行，但是一来影响性能，二来如果暴露了 pprof 接口，也不太安全。

那还有什么办法，可以不用改代码，直接现场诊断呢？

还真有，那就是 delve 调试工具。这个答案应该不是很难想到，但是鉴于好像确实没什么文章介绍这种方法。那就我来吧。下面就介绍一下怎么使用 delve 现场诊断协程泄露问题。

安装 delve

或许最难的一步就是安装 delve。认真的，没开玩笑。在开发环境，我们安装个软件当然是易如反掌。但是要在生产环境，服务器上安装东西，那就说不准有多少艰难险阻了。

delve 一般是通过命令 go install github.com/go-delve/delve/cmd/dlv@master 安装。但是就要求服务器安装了 go 并且能够连接外部网络。这已经是比较苛刻的要求了。

最低要求就是能够连接服务器，并且能够把 delve 传上去。否则就不太好办了。

如果是通过镜像部署的应用，我觉得在打镜像时把 delve 添加进去是个不错的主意，体积不大，还能防不时之需。

连接程序

第二步就是连接程序，开始 debug 了，这个比较简单，两个命令就能解决。

ps -aux |grep $name # 查询 pid， $name 替换为程序名字

dlv attach $pid # 连接程序，$pid 替换为上一步查询到的 pid

显示协程信息

在执行 dlv attach 命令后，就会进入 dlv 的交互控制台。最简单的话，输入 grs 就能显示协程信息，但在协程泄露的情况下，做一些过滤和分组可以看的更清楚一点，命令如下：

grs -w user -group goloc

表示只显示用户协程，并按调起协程的位置分组统计。详细信息可以通过 help grs 命令查看。

演示

下面我用一个非常经典的协程泄露场景来演示下：

func main() {
    for {
        queryAll()
    }
}

func queryAll() int {
    ch := make(chan int)
    for i := 0; i < 3; i++ {
        go func() { ch <- query() }()
    }
    return <-ch
}

func query() int {
    n := rand.Intn(100) + 100
    time.Sleep(time.Duration(n) * time.Millisecond)
    return n
}

这个代码模拟了 只取返回最快的结果，其他结果被遗弃后一直阻塞发送协程的情况。

运行程序一段时间后，用 dlv 执行 grs -w user -group goloc 后输出是这样的：

Type 'help' for list of commands.
(dlv) grs -w user -group goloc
<autogenerated>:1 in runtime.newproc
          Goroutine 1 - User: C:/Work/my-project/learn/main.go:19 main.queryAll (0x8dba37) [chan receive]
        Total: 1

C:/Work/my-project/learn/main.go:17 in main.queryAll
          Goroutine 18 - User: C:/Work/my-project/learn/main.go:17 main.queryAll.func1 (0x8dba90) [chan send]
          Goroutine 6 - User: C:/Work/my-project/learn/main.go:17 main.queryAll.func1 (0x8dba90) [chan send]
          Goroutine 7 - User: C:/Work/my-project/learn/main.go:17 main.queryAll.func1 (0x8dba90) [chan send]
          Goroutine 19 - User: C:/Work/my-project/learn/main.go:17 main.queryAll.func1 (0x8dba90) [chan send]
          Goroutine 51 - User: C:/Work/my-project/learn/main.go:17 main.queryAll.func1 (0x8dba90) [chan send]
        Total: 333
(dlv)

可以看到，queryAll 一共有 333 个协程，并都处于 chan send 状态。说明发送被阻塞了，有了这个信息，问题就很清晰明白了。

注意事项

dlv debug 时也会使得内存占用变高，如果内存已经过高，那么可能加快引起 OOM。

本作品采用《CC 协议》，转载必须注明作者和本文链接