堆大小变化和活动堆数在 gctrace=1 中的含义

积累知识，胜过积蓄金银！毕竟在Golang开发的过程中，会遇到各种各样的问题，往往都是一些细节知识点还没有掌握好而导致的，因此基础知识点的积累是很重要的。下面本文《堆大小变化和活动堆数在 gctrace=1 中的含义》，就带大家讲解一下知识点，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

设置 godebug=gctrace=1 会导致 go 垃圾收集器向有关每个 gc 轮的内部信息的标准错误发出一行。假设我有这个输出：

gc 1 @0.021s 0%: 0.15+0.37+0.25 ms clock, 3.0+0.19/0.39/0.60+5.0 ms cpu, 4->4->0 mb, 5 mb goal, 48 p
gc 2 @0.024s 0%: 0.097+0.94+0.16 ms clock, 0.29+0.21/1.3/0+0.49 ms cpu, 4->4->1 mb, 5 mb goal, 48 p
gc 3 @0.027s 1%: 0.10+0.43+0.17 ms clock, 0.60+0.48/1.5/0+1.0 ms cpu, 4->4->0 mb, 5 mb goal, 48 p
gc 4 @0.028s 1%: 0.18+0.41+0.28 ms clock, 0.18+0.69/2.0/0+0.28 ms cpu, 4->4->0 mb, 5 mb goal, 48 p
gc 5 @0.031s 1%: 0.078+0.35+0.29 ms clock, 1.1+0.26/2.0/0+4.4 ms cpu, 4->4->0 mb, 5 mb goal, 48 p
gc 6 @0.032s 1%: 0.11+0.50+0.32 ms clock, 0.22+0.99/2.3/0+0.64 ms cpu, 4->4->0 mb, 5 mb goal, 48 p
gc 7 @0.034s 1%: 0.18+0.39+0.27 ms clock, 0.18+0.56/2.2/0+0.27 ms cpu, 4->4->0 mb, 5 mb goal, 48 p
gc 8 @0.035s 2%: 0.12+0.40+0.27 ms clock, 0.12+0.63/2.2/0+0.27 ms cpu, 4->4->0 mb, 5 mb goal, 48 p
gc 9 @0.036s 2%: 0.13+0.41+0.26 ms clock, 0.13+0.52/2.2/0+0.26 ms cpu, 4->4->0 mb, 5 mb goal, 48 p
gc 10 @0.038s 2%: 0.099+0.51+0.20 ms clock, 0.19+0.56/1.9/0+0.40 ms cpu, 4->5->0 mb, 5 mb goal, 48 p
gc 11 @0.039s 2%: 0.10+0.46+0.20 ms clock, 0.10+0.23/1.3/0.005+0.20 ms cpu, 4->4->0 mb, 5 mb goal, 48 p
gc 12 @0.040s 2%: 0.066+0.46+0.24 ms clock, 0.93+0.40/1.7/0+3.4 ms cpu, 4->4->0 mb, 5 mb goal, 48 p
gc 13 @0.041s 2%: 0.099+0.30+0.20 ms clock, 0.099+0.60/1.7/0+0.20 ms cpu, 4->4->0 mb, 5 mb goal, 48 p
gc 14 @0.042s 2%: 0.095+0.45+0.24 ms clock, 0.38+0.58/2.0/0+0.98 ms cpu, 4->5->0 mb, 5 mb goal, 48 p
gc 15 @0.044s 2%: 0.095+0.45+0.21 ms clock, 1.0+0.78/1.9/0+2.3 ms cpu, 4->4->0 mb, 5 mb goal, 48 p
gc 16 @0.045s 3%: 0.10+0.45+0.23 ms clock, 0.10+0.70/2.1/0+0.23 ms cpu, 4->5->0 mb, 5 mb goal, 48 p
gc 17 @0.046s 3%: 0.088+0.40+0.17 ms clock, 0.088+0.45/1.9/0+0.17 ms cpu, 4->4->0 mb, 5 mb goal, 48 p
.
.
.
.
gc 6789 @9.998s 12%: 0.17+0.91+0.24 ms clock, 0.85+1.8/5.0/0+1.2 ms cpu, 4->6->1 mb, 6 mb goal, 48 p
gc 6790 @10.000s 12%: 0.086+0.55+0.24 ms clock, 0.78+0.30/4.2/0.043+2.2 ms cpu, 4->5->1 mb, 6 mb goal, 48 p

文档中有这些值的定义：

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

我真正困惑的是 #->#-># mb gc 开始时的堆大小、gc 结束时的堆大小以及实时堆 >。

• 每轮 gc 都会向操作系统释放一些未使用的（垃圾）内存，并且这必须减少堆大小，这是正确的吗？如果是，那么为什么堆的某些值正在增加？例如：4->5->0。 在 gc 开始之前，我们有 4mb 内存，包括垃圾。那么，我们清理掉其中的垃圾后，怎么可能获得5mb内存呢？

• 第三个值是实时堆大小。常规堆大小有什么区别？我认为它是没有垃圾的堆。

• 目标堆大小是如何计算的？ gc 在清理后想要达到的堆大小是否正确？那为什么这个值大于gc开始前的堆大小呢？

解决方案

GC 每次都会清除一些垃圾。它不一定将其释放给操作系统（如果它认为只需很快再次请求它）；如果确实如此，操作系统不一定会回收它（直到存在来自另一个进程的内存压力，操作系统可能会将该内存分配给您的进程，以防它再次需要）。

活动堆大小是指正在使用的堆的大小，减去任何死对象和可供将来分配的可用堆空间。目标堆大小是 GC 认为需要从操作系统获取多少内存来持续处理进程的分配，而不必不断地从操作系统请求更多内存（即，有多少内存保持活动状态 + 在 GC 之间分配和丢弃了多少内存）运行）。

GC 的目标是清理堆中的死对象，并且维护足够的可用堆空间来处理大多数分配，而不必向操作系统请求更多内存（这很慢），同时也不保留过多的可用内存（以便操作系统仍然可以分配给其他进程）。

终于介绍完啦！小伙伴们，这篇关于《堆大小变化和活动堆数在 gctrace=1 中的含义》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布Golang相关知识，快来关注吧！