Go -- 中开启gctrace

godebug是一个跨平台的Go程序调试工具，传统的编译型语言调试器使用底层系统调用并读取二进制文件用于调试各类符号。使用起来很麻烦而且很难移植。 

godebug使用不同的方法，直接把源码作为目标程序，在每一行插入调试代码，然后编译并运行。结果就是一个全功能的调试器，完全可以移植到不同平台。事实上，由于有了gopherjs ，你也可以在浏览器上进行调试： 

 

点击此处尝试原文调试窗口。通过原文的“DEBUG IT”按钮，你可以编辑程序并重新调试它。 

工作原理 

下面这张是描述上面例子的矢量图： 

 

从中可以看出原始代码转换了两次：第一次godebug插入调试instrumentation，然后gopherjs将结果编译成JavaScript。 

让我们看一下instrumentation步骤，以下是godebug插入的调用： 

• godebug.EnterFunc：让godebug运行时库知道我们在进入一个函数。由于“next”不停止内部函数调用，运行时库注意这些调用并知道何时跳过这些行。
• godebug.ExitFunc：让godebug运行时库知道我们在离开一个函数，main中省略。
• godebug运行时库：当且仅当用户用命令或一个断点告知其时，使程序暂停并等待输入，暂停时，它会提示用户输入并响应任何命令。
• godebug.Declare：记录变量名和值的映射。该映射通过输出命令使用。

使用godebug 

Step 1.安装 

 

Step 2.设置断点 

在任何想要断点的地方添加这个标记： 

 

由于断点是源代码的一部分，你可以将自己的逻辑置于他们周围。假设你正在运行一个表格驱动多情况测试，其中一个测试输入“weird string”的情况是失败的，那么你可以将下面这个断点放入测试当中： 

 

godebug test将于标记处暂停程序，方便定位。 

Step 3.运行程序 

使用godebug运行命令： 

 

或者对测试来说 ，运行测试命令： 

 

默认情况下，godebug只会添加调试instrumentation到package main（为了godebug运行）或者测试下的package（为了godebug测试）。这意味着在默认情况下，你无法进入来自导入包的函数。当需要的时候，执行下面这个行命令： 

 

最后 

godebug仍然还是一款需要打磨的新工具，目前存在的已知限制包括： 

• 性能开销
• 可能会导致读取冲突，如果你的程序读取自stdin
• 无法附上一个正在运行的进程
• 开始前必须要知道你索要调试的包

其在GitHub上的地址点此进入。

只要在程序执行之前加上环境变量GODEBUG gctrace =1 ，如：
GODEBUG gctrace =1 ./xxxx.exe or GODEBUG gctrace =1 go run main.go

程序将会显示gc信息，如下

gc 1 @2.104s 0%: 0.018+1.3+0.076 ms clock, 0.054+0.35/1.0/3.0+0.23 ms cpu, 4->4->3 MB, 5 MB goal, 4 P
gc 2 @2.241s 0%: 0.019+2.4+0.077 ms clock, 0.079+0/2.4/6.4+0.30 ms cpu, 5->6->5 MB, 6 MB goal, 4 P
gc 3 @2.510s 0%: 0.011+3.2+0.063 ms clock, 0.047+0.10/2.9/9.0+0.25 ms cpu, 11->11->10 MB, 12 MB goal, 4 P
gc 4 @3.021s 0%: 0.013+6.6+0.076 ms clock, 0.053+0.34/6.2/18+0.30 ms cpu, 21->21->20 MB, 22 MB goal, 4 P
gc 5 @3.725s 0%: 0.015+15+0.079 ms clock, 0.062+0.35/15/45+0.31 ms cpu, 40->40->39 MB, 41 MB goal, 4 P
gc 6 @4.741s 0%: 0.008+35+0.17 ms clock, 0.035+0.19/35/100+0.70 ms cpu, 76->76->75 MB, 78 MB goal, 4 P
gc 7 @6.688s 0%: 0.020+117+0.34 ms clock, 0.082+11/117/330+1.3 ms cpu, 147->148->146 MB, 151 MB goal, 4 P
gc 8 @68.645s 0%: 0.019+146+0.30 ms clock, 0.078+0.006/146/407+1.2 ms cpu, 285->285->248 MB, 292 MB goal, 4 P
scvg0: inuse: 426, idle: 0, sys: 427, released: 0, consumed: 427 (MB)
gc 9 @175.448s 0%: 0.030+60+0.12 ms clock, 0.12+0.013/60/177+0.51 ms cpu, 484->484->248 MB, 496 MB goal, 4 P
gc 10 @236.621s 0%: 0.006+59+0.11 ms clock, 0.025+0/59/173+0.47 ms cpu, 484->484->248 MB, 496 MB goal, 4 P
gc 11 @285.967s 0%: 0.027+57+0.22 ms clock, 0.11+0/57/163+0.89 ms cpu, 484->484->248 MB, 496 MB goal, 4 P
scvg1: inuse: 331, idle: 175, sys: 507, released: 0, consumed: 507 (MB)
gc 12 @333.817s 0%: 0.009+52+0.18 ms clock, 0.036+0/52/155+0.72 ms cpu, 484->484->248 MB, 496 MB goal, 4 P

gc信息的含义

查看官方的runtime说明：

gctrace: setting gctrace=1 causes the garbage collector to emit a single line to standard
error at each collection, summarizing the amount of memory collected and the
length of the pause. Setting gctrace=2 emits the same summary but also
repeats each collection. The format of this line is subject to change.
Currently, it is:
    gc # @#s #%: #+#+# ms clock, #+#/#/#+# ms cpu, #->#-># MB, # MB goal, # P
where the fields are as follows:
    gc #        the GC number, incremented at each GC
    @#s         time in seconds since program start
    #%          percentage of time spent in GC since program start
    #+...+#     wall-clock/CPU times for the phases of the GC
    #->#-># MB  heap size at GC start, at GC end, and live heap
    # MB goal   goal heap size
    # P         number of processors used
The phases are stop-the-world (STW) sweep termination, concurrent
mark and scan, and STW mark termination. The CPU times
for mark/scan are broken down in to assist time (GC performed in
line with allocation), background GC time, and idle GC time.
If the line ends with "(forced)", this GC was forced by a
runtime.GC() call and all phases are STW.

Setting gctrace to any value > 0 also causes the garbage collector
to emit a summary when memory is released back to the system.
This process of returning memory to the system is called scavenging.
The format of this summary is subject to change.
Currently it is:
    scvg#: # MB released  printed only if non-zero
    scvg#: inuse: # idle: # sys: # released: # consumed: # (MB)
where the fields are as follows:
    scvg#        the scavenge cycle number, incremented at each scavenge
    inuse: #     MB used or partially used spans
    idle: #      MB spans pending scavenging
    sys: #       MB mapped from the system
    released: #  MB released to the system
    consumed: #  MB allocated from the system

垃圾回收信息
gc 1 @2.104s 0%: 0.018+1.3+0.076 ms clock, 0.054+0.35/1.0/3.0+0.23 ms cpu, 4->4->3 MB, 5 MB goal, 4 P。

1 表示第一次执行
@2.104s 表示程序执行的总时间
0% 垃圾回收时间占用的百分比，（不知道和谁比？难道是和上面的程序执行总时间，这样比较感觉没意义）
0.018+1.3+0.076 ms clock 垃圾回收的时间，分别为STW（stop-the-world）清扫的时间, 并发标记和扫描的时间，STW标记的时间
0.054+0.35/1.0/3.0+0.23 ms cpu 垃圾回收占用cpu时间
4->4->3 MB 堆的大小，gc后堆的大小，存活堆的大小
5 MB goal 整体堆的大小
4 P 使用的处理器数量

系统内存回收信息,这个很直白，看单词就知道大概意思了
scvg0: inuse: 426, idle: 0, sys: 427, released: 0, consumed: 427 (MB)

426 使用多少M内存
0 剩下要清除的内存
427 系统映射的内存
0 释放的系统内存
427 申请的系统内存