Go goroutine 数量持续上涨怎样区分泄漏类型

线上看到 runtime.NumGoroutine() 从几百一路涨到几万，先别急着把它叫作“泄漏”。最可靠的判断是：流量回落后数量是否仍不回落，两个时间点的 goroutine 栈是否反复落在同一段业务代码，以及这些 goroutine 是否被同步原语、I/O 或主动循环卡住。实践中可以先把增长分成三类，再决定修复方向。

先用两个时间点确认是不是异常增长

单次数量高不等于泄漏。批量任务、连接建立和启动预热都可能让 goroutine 短暂上升。先记录请求量、活跃任务数和 goroutine 数，等一轮请求结束后再取第二个点。如果请求量已经回落，goroutine 数仍按近似固定斜率增长，或者同一调用栈的数量持续增加，才进入泄漏排查。

package main

import (
    "log"
    "runtime"
    "time"
)

func sampleGoroutines() {
    ticker := time.NewTicker(15 * time.Second)
    defer ticker.Stop() // 采样协程退出时释放 ticker，避免留下新的资源
    for range ticker.C {
        log.Printf("goroutines=%d", runtime.NumGoroutine()) // 只记录趋势，不把单点当结论
    }
}

采样器本身也必须有生命周期；如果它只服务于一次任务，应改成接收 context.Context 并在取消时返回。

你可以通过pprof采集运行时栈信息，按阻塞来源把goroutine泄漏分成通道阻塞、互斥锁抢占超时、goroutine被逻辑挂起三类，不需要额外引入复杂工具就能完成初步区分。

用 goroutine profile 区分三种增长形态

给服务接入受保护的 net/http/pprof 后，先抓普通 profile，再间隔一到三分钟抓一次。下面的命令只展示分析路径，地址应替换为内部调试端口，并限制访问来源。

# 第一个时间点保存全部 goroutine 栈，便于和稍后的 profile 对比
curl -s http://127.0.0.1:6060/debug/pprof/goroutine > goroutine-a.prof

# 相隔一段稳定窗口后再抓第二个时间点，并查看重复栈的汇总
curl -s http://127.0.0.1:6060/debug/pprof/goroutine > goroutine-b.prof
go tool pprof -top goroutine-b.prof

两个 profile 的差异比单个数字更有用：如果新增数量都落到同一行发送或接收代码，优先修通道的生命周期；如果栈分散在外部调用，先补超时和取消；如果栈持续运行，则不能只靠等待 GC。

支持时再用 goroutineleak profile 做确认

较新的 Go 运行时提供 goroutineleak profile。它会配合 GC 判断被 channel、阻塞式 select、sync.Mutex、RWMutex、WaitGroup 或 Cond 卡住、且同步原语已经不可达的 goroutine。可以这样采集：

# 只拉取运行时识别出的泄漏候选；旧运行时可能没有这个端点
curl -s http://127.0.0.1:6060/debug/pprof/goroutineleak > goroutine-leak.prof
go tool pprof -top goroutine-leak.prof

这个 profile 不是“所有泄漏检测器”。网络 I/O、文件 I/O、死循环、无限重试，以及仍被全局变量持有的同步原语，都可能不出现在结果里。因此空结果只能说明这一类阻塞未被识别，不能证明 goroutine 数量上涨是正常的。生产环境还要把 pprof 放在独立端口或受控路由后面，避免把栈信息直接暴露给公网。

修复时把退出权交给生命周期所有者

最常见的修复不是向 goroutine 里再加一个 sleep，而是让创建它的任务拥有取消权，并让发送、接收、等待和外部调用都能响应取消。下面的 worker 同时处理了 channel 关闭和上下文取消：

func worker(ctx context.Context, jobs 

如果业务允许部分结果，发送端可以使用带容量的 channel 或带取消分支的发送；如果是 HTTP、数据库或 RPC 调用，要确认下游真的接收并传递了 context。修复后先在压测或灰度实例重复采集两个时间点，再观察基线是否回落。

把告警和回滚条件写进运行手册

告警不要只设一个绝对阈值。更实用的是同时看 goroutine 数、请求量、活跃任务数和增长斜率，并在发布后对比同一实例的基线。出现异常时先降低触发源或摘除灰度实例，保留两个 profile；修复验证后再恢复流量。若 profile 显示是正常批处理峰值，就调整基线，不要为了压低数字强行杀掉后台任务。

相关问题

goroutine 数量高但没有继续上涨，需要修复吗？

不一定。只要和稳定流量、任务量相符且 profile 中是预期的后台工作，可以先记录基线；持续上涨或请求结束后不回落才更像泄漏。

goroutineleak 为空是不是没有泄漏？

不是。它只覆盖特定同步原语和可达性条件；I/O 等待、无限循环和全局可达对象仍要用普通 profile、超时审查和业务指标排查。

为什么一定要抓两个时间点？

单个 profile 只能告诉你当前状态，两个时间点才能看到哪些调用栈在增加，并把正常的并发峰值和持续堆积分开。