如何排查 Go 程序的内存泄漏（Memory Leak）？

知识点图片

排查 Go 程序的内存泄漏（Memory Leak）是一个系统性的过程。由于 Go 带有垃圾回收（GC）机制，真正的“内存泄漏”（即内存无法被回收且无法被访问）比较少见，绝大多数情况是“逻辑泄漏”，即对象依然被引用（Reachable），导致 GC 无法回收它们，但程序逻辑上其实已经不再需要这些对象了。

以下是排查 Go 内存泄漏的完整步骤和指南：

第一阶段：确认是否存在泄漏

在深入代码之前，先通过监控确认内存是否真的在持续增长且不下降。

观察指标：
- RSS (Resident Set Size): 操作系统视角的物理内存占用。
- Go Heap Inuse: Go Runtime 实际使用的堆内存。
判断标准：
- 如果 RSS 持续上涨，且在业务低峰期（或强制 GC 后）没有明显回落，通常存在泄漏。
- 如果 RSS 很高，但 Heap Inuse 很低，可能是内存碎片或 非 Go 内存泄漏（如 CGo）。

第二阶段：使用 pprof 进行定位（核心步骤）

pprof 是 Go 官方提供的最强大的性能分析工具。

1. 开启 pprof

在代码中引入 net/http/pprof：

import _ "net/http/pprof"

func main() {
    // 启动一个专门用于 pprof 的 HTTP 服务
    go func() {
        log.Println(http.ListenAndServe("localhost:6060", nil))
    }()
    // ... 业务代码
}

2. 抓取 Heap Profile

在内存增长的过程中，抓取堆内存快照。

命令行方式：
bash
```
go tool pprof -http=:8080 http://localhost:6060/debug/pprof/heap
```
这会在浏览器打开一个可视化界面。
关注指标：
- inuse_space: 最重要。显示当前正被使用的内存（尚未释放）。排查泄漏主要看这个。
- alloc_space: 显示历史上分配过的总内存（包括已释放的）。主要用于排查频繁分配导致的 GC 压力，而非泄漏。

3. 使用 diff 模式对比（杀手锏）

这是定位泄漏最有效的方法。你需要抓取两个时间点的快照进行对比：

Base: 程序启动一段时间，内存趋于稳定时。
bash
```
curl http://localhost:6060/debug/pprof/heap > base.heap
```

Current: 运行一段时间，内存明显增长后。

bash

curl http://localhost:6060/debug/pprof/heap > current.heap

对比:
bash
```
go tool pprof -http=:8080 -base base.heap current.heap
```
解释：浏览器中显示的将是这两个时间点之间新增且未释放的内存对象。重点关注正值很大的部分。

第三阶段：常见泄漏原因分析

通过 pprof 定位到具体的函数或对象后，对照以下常见模式进行代码审查：

1. Goroutine 泄漏（最常见）

如果 Goroutine 启动后因为某种原因阻塞（死锁、等待 nil channel、死循环），它占用的栈内存和引用的堆对象永远不会被释放。

排查方法：查看 http://localhost:6060/debug/pprof/goroutine?debug=1，看 Goroutine 数量是否持续增长。
常见场景：
- 发送到没有接收者的 Channel。
- 从没有发送者的 Channel 接收。
- select 语句没有 default 分支且被阻塞。

2. Time.Ticker 未停止

使用 time.NewTicker 创建定时器，如果不显式调用 Stop()，Ticker 相关的 channel 和结构体不会被 GC 回收。

// 错误示例
func bad() {
    ticker := time.NewTicker(1 * time.Second)
    for range ticker.C {
        // ...
        if done {
            return // ticker 泄漏了
        }
    }
}

// 修正
defer ticker.Stop()

3. 切片（Slice）引用大数组

Go 的切片共享底层数组。如果你加载了一个巨大的数据到内存（如读取大文件），然后基于它切片取了一小部分并长期持有，那么整个底层大数组都无法被回收。

var keep []byte

func load() {
    data := make([]byte, 100*1024*1024) // 100MB
    keep = data[:10] // 虽然只用了10字节，但底层100MB内存无法释放
}

// 修正：使用 copy 或 strings.Clone (Go 1.18+)
func fix() {
    data := make([]byte, 100*1024*1024)
    keep = make([]byte, 10)
    copy(keep, data[:10])
}

4. 全局变量/缓存无限增长

使用 map 作为缓存，但没有设置过期清理机制或最大容量限制。

特征：pprof 指向全局 map 变量。
解决：使用 LRU Cache 库，或定期清理 map。

5. Finalizer 问题

使用 runtime.SetFinalizer 可能导致对象生命周期延长，甚至在循环引用时导致无法回收。

第四阶段：特殊情况排查

如果 go tool pprof 显示 Heap Inuse 很低，但 OS 看到的 RSS 很高：

1. 内存碎片（Fragmentation）

Go 向操作系统申请内存是按页（Page）管理的。如果大量小对象释放后，内存页中仍有少量对象存活，该页就无法归还给 OS。

排查：查看 memstats 中的 HeapReleased。
解决：
- 优化数据结构，减少小对象分配。
- Go 1.12+ 使用 MADV_FREE，可能导致 RSS 不立即下降（这是正常的，OS 需要时会回收）。
- 尝试设置环境变量 GODEBUG=madvdontneed=1 (强制归还内存给 OS，Linux 下常用)。

2. CGo 泄漏

如果你的程序使用了 CGo，C 代码中 malloc 的内存 Go 的 GC 是管不到的。

排查：pprof 看不到这部分内存。需要使用 valgrind 或 gdb 等 C/C++ 工具排查。

3. Go Runtime 自身开销

高并发下，Runtime 可能会保留大量内存用于调度和 GC 及其元数据。

总结排查清单

看监控：确认是真泄漏（持续上涨）还是假象（RSS 高但平稳）。
抓 pprof：
- goroutine profile：看协程数是否爆炸。
- heap profile：看 inuse_space。
做 Diff：对比 Base 和 Current 的堆快照，找到增量来源。
查代码：
- Ticker 停了吗？
- Goroutine 退出了吗？
- Map 是否只增不减？
- Slice 是否引用了大底层数组？
调参数：如果是碎片问题，考虑 GODEBUG=madvdontneed=1 或调整 GOGC / GOMEMLIMIT。

播面