Go语言内存泄漏常见场景_Golang goroutine与资源泄漏排查-Golang-PHP中文网

go中真正内存泄漏少见，多数是goroutine泄漏或资源未释放所致：numgoroutine持续上涨、tcp.inuse居高不下、heap_inuse不回落；pprof可见大量chan receive/select卡死，阻塞时间长达数小时，堆栈指向net/http.readloop等；主因包括nil channel操作、无缓冲channel收发失配、for range未close、context未传递超时、http client/server超时缺失、io.closer未close、context传递断裂等。

go语言内存泄漏常见场景_golang goroutine与资源泄漏排查

Go 里真正“内存泄漏”少见，绝大多数是 goroutine 泄漏或资源未释放导致的持续性内存/句柄占用。这类问题不报错、不 panic，但会缓慢拖垮服务——NumGoroutine 持续上涨、net.sockets.tcp.inuse 居高不下、heap_inuse 不回落，基本可以锁定。

goroutine 泄漏：pprof 看到大量 chan receive/select 卡死

这是最典型的现象。访问 /debug/pprof/goroutine?debug=2，如果返回中反复出现：

状态为 chan receive 或 select，且阻塞时间长达数小时（如 432000s）
堆栈指向 net/http.readLoop、golang.org/x/crypto/ssh、或你自定义的 for range ch 循环
同一类调用栈数量随请求线性增长

说明 goroutine 已卡死，无法退出。常见原因包括：

var c chan int 后直接 或 <code>c ：向 nil channel 操作，永久阻塞
无缓冲 channel 写入后，接收方未启动或已退出，且未 close(ch)
for range ch 但没人关 channel；或 select 所有 case 都不可达且无 default
HTTP handler 中启了 go func() { ... }()，但没绑定 req.Context()，也没监听 ctx.Done()

http.Client 和 http.Server 超时缺失：连接堆积成协程海

客户端和服务端两端都可能出问题，且常一起发生：

上游 client 用 http.DefaultClient 或未设 timeout 的自定义 client，保持 keepalive 连接不释放
本服务 http.Server 未设置 ReadTimeout、WriteTimeout、IdleTimeout，导致空闲连接长期滞留
后果不是报错，而是每个空闲连接背后都挂着一个 readLoop + writeLoop goroutine，持续吃内存和文件句柄

修复方式：

服务端：显式配置超时，例如 srv := &http.Server{Addr: ":8080", ReadTimeout: 5 * time.Second, IdleTimeout: 30 * time.Second}
客户端：始终用 http.NewRequestWithContext(ctx, ...)，并设置 transport.MaxIdleConnsPerHost = 32 等限制
别依赖 DefaultClient，它没有超时、没有连接池限制

资源未 Close：file / db / resp.Body 堆积成系统瓶颈

所有实现了 io.Closer 接口的对象，都必须显式 Close()。漏掉一个，就可能拖垮整个进程：

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

os.Open 后忘了 defer f.Close() → 文件句柄耗尽，open too many files
sql.Open 创建的 *sql.DB 未调用 db.Close() → 连接池不释放，最终 DB 拒绝新连接
resp, err := client.Do(req) 后只检查 err，却没 defer resp.Body.Close() → 底层 persistConn 无法复用或回收，引发 goroutine 泄漏