用 GODEBUG 看 GC

什么是 GC

在计算机科学中，垃圾回收（GC）是一种自动管理内存的机制，垃圾回收器会去尝试回收程序不再使用的对象及其占用的内存。而最早 John McCarthy 在 1959 年左右发明了垃圾回收，以简化 Lisp 中的手动内存管理的机制（来自 wikipedia）。

为什么要 GC

手动管理内存挺麻烦，管错或者管漏内存也很糟糕，将会直接导致程序不稳定（持续泄露）甚至直接崩溃。

GC 带来的问题

硬要说会带来什么问题的话，也就数大家最关注的 Stop The World（STW），STW 代指在执行某个垃圾回收算法的某个阶段时，需要将整个应用程序暂停去处理 GC 相关的工作事项。例如：

如何调整 GC 频率

可以通过 GOGC 变量设置初始垃圾收集器的目标百分比值，对比的规则为当新分配的数值与上一次收集后剩余的实时数值的比例达到设置的目标百分比时，就会触发 GC，默认值为 GOGC=100。如果将其设置为 GOGC=off 可以完全禁用垃圾回收器，要不试试？

简单来讲就是，GOGC 的值设置的越大，GC 的频率越低，但每次最终所触发到 GC 的堆内存也会更大。

各版本 GC 情况

注：资料来源于 @boya 在深圳 Gopher Meetup 的分享。

GODEBUG

GODEBUG 变量可以控制运行时内的调试变量，参数以逗号分隔，格式为：name=val。本文着重点在 GC 的观察上，主要涉及 gctrace 参数，我们通过设置 gctrace=1 后就可以使得垃圾收集器向标准错误流发出 GC 运行信息。

涉及术语

• mark：标记阶段。
• markTermination：标记结束阶段。
• mutator assist：辅助 GC，是指在 GC 过程中 mutator 线程会并发运行，而 mutator assist 机制会协助 GC 做一部分的工作。
• heap_live：在 Go 的内存管理中，span 是内存页的基本单元，每页大小为 8kb，同时 Go 会根据对象的大小不同而分配不同页数的 span，而 heap_live 就代表着所有 span 的总大小。
• dedicated / fractional / idle：在标记阶段会分为三种不同的 mark worker 模式，分别是 dedicated、fractional 和 idle，它们代表着不同的专注程度，其中 dedicated 模式最专注，是完整的 GC 回收行为，fractional 只会干部分的 GC 行为，idle 最轻松。这里你只需要了解它是不同专注程度的 mark worker 就好了，详细介绍我们可以等后续的文章。

演示代码

func main() {
    wg := sync.WaitGroup{}
    wg.Add(10)
    for i := 0; i < 10; i++ {
        go func(wg *sync.WaitGroup) {
            var counter int
            for i := 0; i < 1e10; i++ {
                counter++
            }
            wg.Done()
        }(&wg)
    }

    wg.Wait()
}

gctrace

$ GODEBUG=gctrace=1 go run main.go    
gc 1 @0.032s 0%: 0.019+0.45+0.003 ms clock, 0.076+0.22/0.40/0.80+0.012 ms cpu, 4->4->0 MB, 5 MB goal, 4 P
gc 2 @0.046s 0%: 0.004+0.40+0.008 ms clock, 0.017+0.32/0.25/0.81+0.034 ms cpu, 4->4->0 MB, 5 MB goal, 4 P
gc 3 @0.063s 0%: 0.004+0.40+0.008 ms clock, 0.018+0.056/0.32/0.64+0.033 ms cpu, 4->4->0 MB, 5 MB goal, 4 P
gc 4 @0.080s 0%: 0.004+0.45+0.016 ms clock, 0.018+0.15/0.34/0.77+0.065 ms cpu, 4->4->1 MB, 5 MB goal, 4 P
gc 5 @0.095s 0%: 0.015+0.87+0.005 ms clock, 0.061+0.27/0.74/1.8+0.023 ms cpu, 4->4->1 MB, 5 MB goal, 4 P
gc 6 @0.113s 0%: 0.014+0.69+0.002 ms clock, 0.056+0.23/0.48/1.4+0.011 ms cpu, 4->4->1 MB, 5 MB goal, 4 P
gc 7 @0.140s 1%: 0.031+2.0+0.042 ms clock, 0.12+0.43/1.8/0.049+0.17 ms cpu, 4->4->1 MB, 5 MB goal, 4 P
...

格式

gc # @#s #%: #+#+# ms clock, #+#/#/#+# ms cpu, #->#-># MB, # MB goal, # P

含义

• gc#：GC 执行次数的编号，每次叠加。
• @#s：自程序启动后到当前的具体秒数。
• #%：自程序启动以来在GC中花费的时间百分比。
• #+...+#：GC 的标记工作共使用的 CPU 时间占总 CPU 时间的百分比。
• #->#-># MB：分别表示 GC 启动时, GC 结束时, GC 活动时的堆大小.
• #MB goal：下一次触发 GC 的内存占用阈值。
• #P：当前使用的处理器 P 的数量。

案例

gc 7 @0.140s 1%: 0.031+2.0+0.042 ms clock, 0.12+0.43/1.8/0.049+0.17 ms cpu, 4->4->1 MB, 5 MB goal, 4 P

• gc 7：第 7 次 GC。
• @0.140s：当前是程序启动后的 0.140s。
• 1%：程序启动后到现在共花费 1% 的时间在 GC 上。
• 0.031+2.0+0.042 ms clock：
  • 0.031：表示单个 P 在 mark 阶段的 STW 时间。
  • 2.0：表示所有 P 的 mark concurrent（并发标记）所使用的时间。
  • 0.042：表示单个 P 的 markTermination 阶段的 STW 时间。
• 0.12+0.43/1.8/0.049+0.17 ms cpu：
  • 0.12：表示整个进程在 mark 阶段 STW 停顿的时间。
  • 0.43/1.8/0.049：0.43 表示 mutator assist 占用的时间，1.8 表示 dedicated + fractional 占用的时间，0.049 表示 idle 占用的时间。
  • 0.17ms：0.17 表示整个进程在 markTermination 阶段 STW 时间。
• 4->4->1 MB：
  • 4：表示开始 mark 阶段前的 heap_live 大小。
  • 4：表示开始 markTermination 阶段前的 heap_live 大小。
  • 1：表示被标记对象的大小。
• 5 MB goal：表示下一次触发 GC 回收的阈值是 5 MB。
• 4 P：本次 GC 一共涉及多少个 P。

总结

通过本章节我们掌握了使用 GODEBUG 查看应用程序 GC 运行情况的方法，只要用这种方法我们就可以观测不同情况下 GC 的情况了，甚至可以做出非常直观的对比图，大家不妨尝试一下。

关联文章

• 用 GODEBUG 看调度跟踪

参考

• Go GC打印出来的这些信息都是什么含义？
• GODEBUG之gctrace解析
• 关于Golang GC的一些误解–真的比Java GC更领先吗？
• @boya 深入浅出Golang Runtime PPT