许多人在刚开始接触 Go 语言时，经常会有的疑惑就是“为什么一个 Hello world 会占用如此之多的内存？”。Understanding Go Lang Memory Usage 很好的解释了这个问题。不过“简介”就是“简介”，更加深入的内容恐怕要读者自己去探索了。另外，文章写到最后，作者飘了，估计引起了一些公愤，于是又自己给自己补刀，左一刀，右一刀……

————翻译分隔线————

理解 Go 语言的内存使用

2014年12月22日，星期一

温馨提示：这仅是关于 Go 语言内存的简介，俗话说不入虎穴、焉得虎子，读者可以进行更加深入的探索。

大多数 Go 开发者都会尝试像这样简单的 hello world 程序：

package main

import (
"fmt"
"time"
)

func main() {
fmt.Println("hi")

time.Sleep(30 * time.Second)
}

然后他们就完全崩溃了。

f!*%!$%@# 138 G？！这个笔记本也只有 16 G 内存！

虚拟内存 vs 常驻内存

Go 管理内存的方式可能与你以前使用的方式不太一样。它会在一开始就保留一大块 VIRT，而 RSS 与实际内存用量接近。

RSS 和 VIRT 之间有什么区别呢？

VIRT 或者虚拟地址空间大小是程序映射并可以访问的内存数量。

RSS 或者常驻大小是实际使用的内存数量。

如果你对 Go 到底是怎么实现的感兴趣，来看看这个：

https://github.com/golang/go/blob/master/src/runtime/malloc1.go

    // 在 64 位设备中，从单一的连续保留地址中分配。
    // 当前来说 128 GB (MaxMem) 应当是足够了。

    // 实际上我们保留了 136 GB（因为最终位映射会使用 8 GB）

务必注意，如果你使用 32 位的架构，内存保留机制是完全不同的。

垃圾收集

现在我们已经清楚了常驻内存和共享内存的区别，可以来谈谈 Go 进行垃圾收集的机制，以便了解我们的程序是如何工作的。

设想你正在编写一个长期运行的后台服务，就让它是一个 web 应用服务或者某些更复杂的东西。通常来说，在整个运行周期都会需要分配内存。了解如何处理这些内存是必要的。

通常，每 2 分钟会执行一次垃圾收集。如果某个片段持续 5 分钟都没有被使用，回收器会将其释放。

因此，如果你认为内存使用会降低，那么 7 分钟之后再去确认吧。

需要注意的是，当前 gc 是非压缩的，也就是说如果你在某个页面有一个字节正在使用，回收器会拒绝释放这个页面。

最后，也是最重要的，Go 1.3 的 goroutine 栈有 8k/pop 的空间不会被释放，它们随后会被重用。不用担心，Go 在 GC 的部分还有很大的改进空间。因此，如果你的代码会产生大量的 goroutine，并且 RES 居高不下的话，这可能就是原因。

好了，现在我们已经知道了程序从外部看到的样子以及期望 GC 做的工作。

分析内存使用

现在通过一个小例子来看看如何了解内存使用。在这个例子中，我们将分配 10 组 100 兆字节的内存。

然后会用多种方式来了解内存的使用。

一个方法是通过 runtime 包的 ReadMemStats 函数。

另一个方法是通过 pprof 包提供的 web 接口。这允许我们远程获得程序的 pprof 数据，稍候会详细解释。

还有一种方法是我们必须介绍的是 Dave Cheney 提到的，使用 gctrace 调试环境变量。

注意：这些都在 64 位 Linux 下的 Go 1.4 环境下完成。

package main

import (
        "log"
        "net/http"
        _ "net/http/pprof"
        "runtime"
        "sync"
)

func bigBytes() *[]byte {
        s := make([]byte, 100000000)
        return &s
}

func main() {
        var wg sync.WaitGroup

        go func() {
                log.Println(http.ListenAndServe("localhost:6060", nil))
        }()

        var mem runtime.MemStats
        runtime.ReadMemStats(&mem)
        log.Println(mem.Alloc)
        log.Println(mem.TotalAlloc)
        log.Println(mem.HeapAlloc)
        log.Println(mem.HeapSys)

        for i := 0; i < 10; i++ {
                s := bigBytes()
                if s == nil {
                        log.Println("oh noes")
                }
        }

        runtime.ReadMemStats(&mem)
        log.Println(mem.Alloc)
        log.Println(mem.TotalAlloc)
        log.Println(mem.HeapAlloc)
        log.Println(mem.HeapSys)

        wg.Add(1)
        wg.Wait()

}

在使用 pprof 查看内存的时候，通常会用到两个选项。

一个选项是“-alloc_space”，用于告诉你已经分配了多少内存。

另一个是“-inuse_space”，用于获得正在使用的内存的数量。

可以运行 pprof 并将其指向我们内建的 web 服务来获得最高的内存消耗。

并且还可以使用 list 来了解那里使用了这些内存：

使用

vagrant@vagrant-ubuntu-raring-64:~/blahdo$ go tool pprof -inuse_space
blahdo http://localhost:6060/debug/pprof/heap
Fetching profile from http://localhost:6060/debug/pprof/heap
Saved profile in
/home/vagrant/pprof/pprof.blahdo.localhost:6060.inuse_objects.inuse_space.025.pb.gz
Entering interactive mode (type "help" for commands)
(pprof) top5
190.75MB of 191.25MB total (99.74%)
Dropped 3 nodes (cum <= 0.96MB)
      flat  flat%   sum%        cum   cum%
  190.75MB 99.74% 99.74%   190.75MB 99.74%  main.main
         0     0% 99.74%   190.75MB 99.74%  runtime.goexit
         0     0% 99.74%   190.75MB 99.74%  runtime.main
(pprof) quit

分配

vagrant@vagrant-ubuntu-raring-64:~/blahdo$ go tool pprof -alloc_space
blahdo http://localhost:6060/de
bug/pprof/heap
Fetching profile from http://localhost:6060/debug/pprof/heap
Saved profile in
/home/vagrant/pprof/pprof.blahdo.localhost:6060.alloc_objects.alloc_space.027.pb.gz
Entering interactive mode (type "help" for commands)
(pprof) top5
572.25MB of 572.75MB total (99.91%)
Dropped 3 nodes (cum <= 2.86MB)
      flat  flat%   sum%        cum   cum%
  572.25MB 99.91% 99.91%   572.25MB 99.91%  main.main
         0     0% 99.91%   572.25MB 99.91%  runtime.goexit
         0     0% 99.91%   572.25MB 99.91%  runtime.main

排行榜已经相当不错了，不过更好的是 list 命令，可以在上下文中看到消耗是如何影响程序的其他部分的。

(pprof) list
Total: 572.75MB
ROUTINE ======================== main.main in
/home/vagrant/blahdo/main.go
  572.25MB   572.25MB (flat, cum) 99.91% of Total
         .          .     23:   var mem runtime.MemStats
         .          .     24:   runtime.ReadMemStats(&mem)
         .          .     25:   log.Println(mem.Alloc)
         .          .     26:
         .          .     27:   for i := 0; i < 10; i++ {
  572.25MB   572.25MB     28:           s := bigBytes()
         .          .     29:           if s == nil {
         .          .     30:                   log.Println("oh noes")
         .          .     31:           }
         .          .     32:   }
         .          .     33:

聪明的读者可能已经发现在上面的内存使用报告中，存在一些差异。为什么会这样呢？

让我们来看看进程：

vagrant@vagrant-ubuntu-raring-64:~$ ps aux | grep blahdo
vagrant   4817  0.2 10.7 699732 330524 pts/1   Sl+  00:13   0:00 ./blahdo

现在来看看日志输出：

./vagrant@vagrant-ubuntu-raring-64:~/blahdo$ ./blahdo
2014/12/23 00:19:37 279672
2014/12/23 00:19:37 336152
2014/12/23 00:19:37 279672
2014/12/23 00:19:37 819200
2014/12/23 00:19:37 300209920
2014/12/23 00:19:37 1000420968
2014/12/23 00:19:37 300209920
2014/12/23 00:19:37 500776960

最后，来看看使用 gctrace 的效果：

vagrant@vagrant-ubuntu-raring-64:~/blahdo$ GODEBUG=gctrace=1 ./blahdo
gc1(1): 1+0+95+0 us, 0 -> 0 MB, 21 (21-0) objects, 2 goroutines, 15/0/0 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields
gc2(1): 0+0+81+0 us, 0 -> 0 MB, 52 (53-1) objects, 3 goroutines, 20/0/0 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields
gc3(1): 0+0+77+0 us, 0 -> 0 MB, 151 (169-18) objects, 4 goroutines, 25/0/0 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields
gc4(1): 0+0+110+0 us, 0 -> 0 MB, 325 (393-68) objects, 4 goroutines, 33/0/0 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields
gc5(1): 0+0+138+0 us, 0 -> 0 MB, 351 (458-107) objects, 4 goroutines, 40/0/0 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields
2014/12/23 02:27:14 277960
2014/12/23 02:27:14 332680
2014/12/23 02:27:14 277960
2014/12/23 02:27:14 884736
gc6(1): 1+0+181+0 us, 0 -> 95 MB, 599 (757-158) objects, 6 goroutines, 52/0/0 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields
gc7(1): 1+0+454+19 us, 95 -> 286 MB, 438 (759-321) objects, 6 goroutines, 52/0/0 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields
gc8(1): 1+0+167+0 us, 190 -> 477 MB, 440 (762-322) objects, 6 goroutines, 54/1/0 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields
gc9(1): 2+0+191+0 us, 190 -> 477 MB, 440 (765-325) objects, 6 goroutines, 54/1/0 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields
2014/12/23 02:27:14 300206864
2014/12/23 02:27:14 1000417040
2014/12/23 02:27:14 300206864
2014/12/23 02:27:14 500842496
GC forced
gc10(1): 3+0+1120+22 us, 190 -> 286 MB, 455 (789-334) objects, 6 goroutines, 54/31/0 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields
scvg0: inuse: 96, idle: 381, sys: 477, released: 0, consumed: 477 (MB)
GC forced
gc11(1): 2+0+270+0 us, 95 -> 95 MB, 438 (789-351) objects, 6 goroutines, 54/39/0 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields
scvg1: 0 MB released
scvg1: inuse: 96, idle: 381, sys: 477, released: 0, consumed: 477 (MB)
GC forced
gc12(1): 85+0+353+1 us, 95 -> 95 MB, 438 (789-351) objects, 6 goroutines, 54/37/0 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields

由于大多数运维工具是站在操作系统的角度来对待你的程序，那么了解程序内部实际发生了什么就变得尤为重要了。

更多选项可以参考 runtime 包。

摘录如下：

• RES – 将会显示在当前时刻进程的内存用量，但可能不包含任何尚未换入或已经换出的页面。
• mem.Alloc – 已经被配并仍在使用的字节数
• mem.TotalAlloc – 从开始运行到现在分配的内存总数
• mem.HeapAlloc – 堆当前的用量
• mem.HeapSys – 包含堆当前和已经被释放但尚未归还操作系统的用量

更进一步说，明白 pprof 仅仅是获取了样本，而不是真正的值，是非常重要的。

通常在处理这个情况的时候，不要聚焦于数字本身，而着眼于解决问题。

我们坚信要测量一切，但是同时觉得“现代”运维工具是相当糟糕的，并聚焦于问题的影响，而不是真正的问题。

如果你的车不能发动了，你可能认为这是个问题，但它不是。这甚至不是邮箱空了的表象。真正的问题在于你没有给邮箱加油，但你关注的是最初的问题导致的一系列的结果。

如果对于 Go 程序你只关注来自 ps 的的 RES 值，它可能告诉你这里出问题了，除非你更进一步挖掘，否则没有任何线索可以解决这个问题。我们希望能更正它。

更正：

最后一段未进行编辑。它并不是用来贬低运维或 devops 人员。其目的在于展示应用级别的度量和系统级别的度量。我们已经意识到这里的表达有误，并且对此道歉。我们只是觉得已有的“运维”工具没有为开发者提供充分的信息来修复他们的问题。

我们同时认为当前应用级别的度量工具仍然匮乏。

运维人员扮演着至关重要的角色，对于他们的工作我们至诚的感谢。事实上，是开发人员糟糕的代码把事情搞麻烦了，这也是我们正在着手解决的问题。

最终更正

与其让运维人员拥有超过 300 个图表包括表格、计数器、点线图和直方图。作为编写软件的我们，应当更加关注找到真正的问题，并提出真正的解决方案。