Go 的内存泄漏

内存泄漏通常在 c/c++ 等语言常见，手工管理内存对程序猿的编程能力有较高要求。最常见的就是分配和释放没有配对使用。

Go 是一门带 Gc 的语言，内存分配位置由编译器推断是在栈还是堆上，内存分配完全由 Go 本身把控，程序猿无法介入。程序猿在前端触发分配，后端的 runtime 的 GC 任务则不断的回收内存，从而达到一个平衡。理论上是不存在常规意义的内存泄漏的。但在程序中，还是经常见到内存占用持续升高的场景，今天就是来分享这类场景的思考。

Go 的内存问题更多的是内存对象的不合理使用，比如一个全局的 map ，程序猿 A 不知什么原因持续往里面添加元素，从来不删。这就是一个典型的内存泄漏（或者叫做内存不合理占用）。也就是说，Go 的内存问题基本都是不合理的业务逻辑导致的。

一般来说，这类内存问题其实非常好排查，怎么排查？

使用 Go 自带的 pprof 工具。

运用 pprof 利器

导入 pprof 包即可，然后开启一个监听端口：

import "net/http"
import _ "net/http/pprof"

func main() {
    // ...
    go func() {
        http.ListenAndServe("0.0.0.0:8080", nil)
    }()
    // ...
}

把程序运行起来，然后直接通过网络接口拿到 pporf 的数据，很方便。

go tool pprof http://127.0.0.1:8080/debug/pprof/allocs

登陆之后 top 就能看到堆栈：

root@ubuntu20:~# go tool pprof http://127.0.0.1:8080/debug/pprof/allocs

(pprof) top
Showing nodes accounting for 1468.90MB, 99.79% of 1471.93MB total
Dropped 22 nodes (cum <= 7.36MB)
      flat  flat%   sum%        cum   cum%
 1270.89MB 86.34% 86.34%  1468.90MB 99.79%  main.main
     198MB 13.45% 99.79%      198MB 13.45%  encoding/base64.(*Encoding).EncodeToString
         0     0% 99.79%      198MB 13.45%  main.EncodeGid
         0     0% 99.79%  1469.90MB 99.86%  runtime.main

pprof 实现的原理其实很简单，就是分配释放的地方做好打点，最好就是能把分配的路径记录下来。举个例子，A 对象分配路径是：main -> fn1 -> fn2 -> fn3 （ 详细的原理可以参考文章：Go内存管理深度细节 ），那么 go 把这个栈路径记录下来即可。这个事情就是在 mallocgc 中实现，每一次的分配都会判断是否要统计采样。

pprof 统计到的比 top 看到的要小？

主要有几个重要原因：1）pprof 有采样周期；2）管理内存+内存碎片；3）cgo 分配的内存 。

pprof 统计到的比实际的小，最重要的原因就是：采样的频率间隔导致的。

采样是有性能消耗的。 毕竟是多出来的操作，每次还要记录堆栈开销是不可忽视的。所以只能在采样的频率上有个权衡，mallocgc 采样默认是 512 KiB，也就是说，进程每分配满 512 KiB 的数据才会记录一次分配路径。

// runtime/mprof.go
var MemProfileRate int = 512 * 1024

// runtime/malloc.go
func mallocgc(size uintptr, typ *_type, needzero bool) unsafe.Pointer {
 // ...
    if rate := MemProfileRate; rate > 0 {
        if rate != 1 && size < c.next_sample {
         // 累积采样
            c.next_sample -= size
        } else {
   // 内存的分配采样入口
            profilealloc(mp, x, size)
        }
    }
    // ...
}

所以这个采样的频率就会导致 pprof 看到的分配、在用内存都比实际的物理内存要小。

有办法影响到加快采样的频率吗？

Go 进程加载的时候，是有机会机会修改这个值的，通过 GODEBUG 来设置 memprofilerate 的值，就会覆盖 MemProfileRate 的默认值。

func parsedebugvars() {

    for p := gogetenv("GODEBUG"); p != ""; {
        // ...
        if key == "memprofilerate" {
            if n, ok := atoi(value); ok {
                MemProfileRate = n
            }
        } else {
            // ...
        }
    }
}

改成 1 的话，每一次分配都要被采样，采样的全面但是性能也是最差的。

Go 使用的是 tcmalloc 的内存分配的模型，把内存 page 按照固定大小划分成小块。这种方式解决了外部碎片，但是小块内部还是有碎片的，这个 gap 也是内存差异的一部分。tcmalloc 内部碎片率整体预期控制在 12.5% 左右。

Go 运行过程中会采样统计内存的分配路径情况，还会时刻关注整体的内存数值，通过 runtime.ReadMemStats 可以获取得到。里面的信息非常之丰富，基本上看一眼就知道内存的一个大概情况，memstat 字段详情（建议收藏）：

其中，内存的 gap 主要来源于：

1. heap 上 Idle span，分配了但是未使用的（往往出现这种情况是一波波的请求峰值导致的，冲上去就一时半会不下来）；
2. stack 的内存占用；
3. OS 分配但是是 reserved 的；
4. runtime 的 Gc 元数据，mcache，mspan 等管理内存；

这部分可大可小，大家记得关注即可。

cgo 分配的内存无法被统计到，这个很容易理解。因为 Go 程序的统计是在 malloc.go 文件 mallocgc 这个函数中，cgo 调用的是 c 程序的代码，八杆子都打不到，它的内存用的 libc 的 malloc ，free 来管理，go 程序完全感知不到，根本没法统计。

所以，如果你的程序遇到了内存问题，并且没用到 cgo ，那么就可以快速 pass ，如果用到了，一般也是排除完前面的所有情况，再来考虑这个因素吧。因为如果真是 cgo 里面分配的内存导致的问题，相当于你要退回到原来 c 语言的排查手段，有点蛋疼。

一个实际的例子

来看一个有趣的例子分析下吧，曾经有个 Go 程序系统 top 看起来 15G，go pprof 只能看到 6G 左右，如下：

top 的样子：

[amy@centos7]$ top

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
499174 service   20   0   19.2g  15.1g   6932 S 635.3 24.3 496911:01 testprog

pprof 看到的：

(pprof) top20
Showing nodes accounting for 6.08GB, 88.63% of 6.86GB total

memstat 看到的：

sys_bytes 1.6808429272e+10    // 16029  // 系统常驻内存，单位是 M

alloc_bytes 1.0527689648e+10  // 10040  // 分配出的对象，且使用的

heap_alloc_bytes 1.0527689648e+10  // 10040  // 堆上分配出来，且在使用的
heap_idle_bytes 4.272185344e+09  // 4074  // 堆上的内存，但是还没人用，等待被使用
heap_inuse_bytes 1.154125824e+10  // 11006  // 堆内存，且在使用的
heap_released_bytes 5.06535936e+08  // 483   // 释放给 os 的堆内存
heap_sys_bytes 1.5813443584e+10  // 15080.8  // 系统占用内存

stack_inuse_bytes 2.424832e+07   // 23   // 栈上的内存
stack_sys_bytes 2.424832e+07   // 23    // 栈上的内存

mcache_inuse_bytes 55552    // 0.05  // mcache 结构的内存占用
mcache_sys_bytes 65536     // 0.06  // mcache 结构的内存占用
mspan_inuse_bytes 1.87557464e+08  // 178.8  // mspan 结构的内存占用
mspan_sys_bytes 2.31292928e+08   // 220.5  // mspan 结构的内存占用

gc_sys_bytes 6.82119168e+08   // 650  // gc 的元数据
buck_hash_sys_bytes 3.86714e+06  // 3.6   // bucket hash 表的开销
other_sys_bytes 5.3392596e+07   // 50   // 用于其他的系统分配出来的内存

next_gc_bytes 1.4926500032e+10   // 14235  // 下一次 gc 的目标内存大小

上面案例数据可以给到我们几个小结论：

1. 系统总内存占用 15+ G 左右；
2. Go heap 总共占用约 15 G ，其中 idle 的内存还挺大的，差不多 4G；
1. 说明有过请求峰值，并且已经过去了
3. mspan，mcache，gc 元数据的内存加起来也到 1G 了，这个值不小了；
4. 下一次 gc 后的目标是 14 G，也就是说至少有 1G 的垃圾；
5. pprof 采样到 6.86 G的内存分配，pprof top 可以看到 Go 的分配详情；

总结

1. Go 的内存问题好排查，用 pprof 能解决 99% 的问题；
2. pprof 采样虽然比实际的分配要少，但不影响问题的排查，看最多的就行，有问题的会一直有问题；
3. memprofilerate 可以影响到采样频率，但一般不建议配置；
4. tcmalloc 的管理方式没有外部碎片，但是有内部碎片，整体碎片率控制在 12 %左右；
5. heap 上的 Idle span 的内存，stack 的内存，runtime 本身结构体的内存，这些内存占用有时候也不小，值得关注；
6. 一般我们不会把问题指向 cgo，除非你用到了 cgo 并且已经排除了所有其他方向；

go全栈开发框架bud，go语言中的ruby on rails

谢孟军：中国 Go 语言领军人创业第五年