乐趣区

关于gc:A-Guide-to-the-Go-Garbage-Collector-翻译Go-语言垃圾回收指南

jiezi

序言

本指南文档通过向纯熟的 Go 用户提供对于 Go GC 一些深刻信息，来帮忙他们更好的对本人程序的运行代价的了解。同时也给 Go 用户提供一份如何深刻洞察优化程序资源利用率的指南。本指南并不假如你相熟 GC，然而对 Go 语言的熟知是必须的。

Go 语言负责管理所有的语言的值(values)，绝大多数状况下，Go 开发者并不需要关注这些值是如何被存储。当然，这些数据实际上是存储在无限的物理内存中的。因为内存的限度，因而它必须被审慎的治理，和被回收重用，防止被一个运行的程序耗尽。依据需要调配和回收内存，是 Go 语言负责的工作。

主动回收利用内存被称为垃圾回收 (garbage collection)。垃圾回收（简称 GC）是一个 回收被判断为程序不会再应用的内存 的零碎。Go 语言提供一个运行时库(runtime library)，它随同每个 Go 程序一起执行，提供了 GC 性能。

请留神，在 Go 语言标准中并没有 确保存在 GC，标准只提到了底层存储的值是由语言本人治理的。（语言标准中的）这项规范是成心脱漏的，它容许理论的（Go 语言实现）应用齐全不同的内存治理技术。

尽管如此，本指南形容的只是 Go 语言的一个特定实现，可能不适用于其余的实现。再具体一点，本指南只针对 Go 语言官网规范工具链 的实现。在 Gccgo 和 Gollvm 这两个实现中 GC 和（规范工具链）十分类似，有大量雷同的概念，然而实现细节可能不一样。

另外，本文档更新以实用与最新的 Go 版本。目前，本文档形容的是 Go 1.19 的 GC。

Go 的值(Values) 存在于哪里

在咱们深刻探讨 GC 之前，先讨论一下那些不须要被 GC 治理的内存。
比方，被存储在 local 变量的非指针值很有可能齐全不须要被 Go GC 治理，而是被调配在它具备雷同的词法作用域的内存中。通常这样会比应用 GC 更加高效，因为 Go 编译器可能事后计算出这块内存什么时候被回收，并且收回清理的指令。咱们称这一类调配为 栈调配，因为他的空间正是存在于在执行代码的 goroutine 堆栈上。

不能被 Go 编译器确定生存期的值不可能在栈调配，他们被叫做逃逸到堆内存（的值）。堆 能够被认为是一个动态分配进去，用于寄存 Go 的值的内存的统称。在堆上分配内存的操作 通常被称为 动态内存调配，编译器和运行时都很难猜想这块内存如何被应用，以及何时它该当被清理。此时 GC 就被引入了：这是一个专门用于标记和清理动静分配内存的零碎。

有许多起因会导致 Go 的值被逃逸到堆上。其中可能的一个起因是，它的大小是动静决定的。比如你有一个数组 slice，他的初始大小是一个变量而不是一个常量决定的。请留神，逃逸是具备传递性的：一个对值援用如果被保留到了另外一个已逃逸了的值内，则它也肯定是逃逸的。

一个值是否逃逸取决于应用它的函数的上下文和 Go 编译器的逃逸剖析算法。当值逃逸的时候，要精准的剖析进去是不靠谱 (fragile) 且艰难的：这个算法自身也是十分的精妙和简单，并且在不同版本中的实现不同。如果想要理解如何定位一个值是否逃逸，能够参考 打消堆调配(eliminating heap allocations)。

跟踪垃圾收集

GC 个别指各种用于主动回收内存的过程，比方援用计数。在本文，GC 特指跟踪垃圾收集 (译注: Tracing Garbage Collection，是一个术语，和它对应的是援用计数)，它 通过跟踪指针的传递来辨认 应用中的 ，被称为 流动 对象，

咱们先严格的定义一些术语：

  • 对象 —— 一个动态分配进去，蕴含一个或多个 Go 值的内存块。
  • 指针 —— 一个对于任何在对象中的值的地址的援用。天然的，形如 *T 的值必定是指针，同时一部分的 Go 内置的值类，包含 string/slice/channel/map/interface 也都蕴含了 GC 必须要追踪的内存地址。

对象和指向其余对象的指针形成了 对象图 (object graph)。为了辨认流动的内存，GC 从程序的根处（被确定为正在应用的对象的指针）遍历对象图。本地变量和全局变量被视为两个典型的 根(root)。遍历对象图这个过程被称为 扫描 (scanning)。

所有的 跟踪垃圾收集 都应用这种通用的算法。不同 跟踪垃圾收集 的异同在于他们发现一旦发现内存流动(live) 之后的做法。Go 的 GC 应用一种叫做 标记 - 革除 (mark-sweep) 的技术，它为了放弃跟踪其进度，会标记遇到的值为 流动 。一旦跟踪操作实现，GC 会再遍历堆内存，将所有未被标记的内存设置为可调配状态。这个过程被称为 革除 (sweeping)。

另外一种你可能相熟的技术，它会把对象挪动到另外的内存区域，留下一个指针，用于接下来更新整个利用的指针。咱们称此类会挪动对象的 GC 为 移动式 GC(a moving GC)，Go 则是 非移动式 GC。(译注：挪动和非移动式 GC 的次要区别在于标记所有流动内存之后，是否把他们拷贝到一块新区域里)

GC 周期

Go GC 是一种 标记 - 革除 类型的 GC，它大抵上被分为两个阶段：标记阶段，和革除阶段。这个形容看起来有些冗余，但它蕴含了一个重要信息：在所有的内存被跟踪之前，内存是无奈被开释的，因为可能存在一些未被扫描的流动对象援用的内存。因而，革除行为必须彻底地和标记行为离开。进一步失去，在无 GC 相干工作执行时，GC 可能是处于彻底的非激活状态。GC 周期 不停的在三个阶段间接循环：革除、进行和标记。对于本文档，咱们认为 GC 周期从革除开始，而后进行，再标记。

接下来的几节内容，咱们会专一给用户建设一种对于 GC 开销的直觉来帮忙大家通过调试 GC 参数获益。

了解开销

GC 自身是一个简单的软件系统，且构建在更加简单的零碎上。在尝试了解原理和调试行为的时候很容易陷入到各种细节中。这一节咱们尝试提供一个框架来了解揣测 Go GC 的开销，并且尝试调优参数。

首先，咱们这个 GC 模型基于三个前提。

  1. GC 只波及到两个计算资源：CPU 耗费工夫和物理内存。

  2. GC 的内存开销包含流动的堆内存，和未标记的新调配的堆内存，对于 metadata 占用的空间，因为和后面的内存比起来太小（而疏忽）。

留神：流动内存是指曾经在前一个 GC 周期内被确认的内存，未标记的新内存则是在本周期内调配的，在周期完结的时候，它可能是流动的也有可能不是。

  1. GC 的 CPU 开销分为两局部：固定开销和随着流动堆内存增长而成比例增长的边际开销(marginal cost)。

留神：（随着内存的增长）渐进地说，革除阶段会比标记和扫描操作性能好转的更快，因为它会随着包含被确定为非流动的整个堆的规模增长而增长。然而，在目前的实现中，革除操作自身要比标记和扫描的开销要快得多，因而在本文探讨中它经常被疏忽掉。

此模型简略然而无效：它精准的把次要的 GC 开销分类解决了。不过这个模型没有对开销的规模解决，以及它们会如何相互影响。为了更好的建模，咱们定义了一种被叫做 稳态 的情景。

  • 程序调配新内存的速度 (bytes 每秒) 是固定的。

注：要明确，这个内存调配速度和新调配的内存有多少会流动是无关的。它可能局部流动，全副流动或者都不流动。（在此之外，一些之前调配的堆内存可能会变为非流动，因而不论新调配的内存多少流动，整个堆大小并不会减少。）

更具体的阐明，构想咱们有一个 web 服务，每一个申请会带来 2M 的堆内存调配。在解决申请过程中，在 2M 内存中最多有 512K 内存是流动的，当整个申请完结的时候，所有调配的内存都会变为非流动。接下来，咱们简略的认为每一个申请会破费 1 秒工夫来解决。而后，咱们有稳固的每秒 100 次的申请，在这种状况下，调配速度是 200M/s，同时会有 50M（额定的）峰值流动堆内存。

  • 程序的对象图在每一个时刻看起来都是差不多统一的（大小，蕴含的指针数量，和图的深度都是近似常量）。
    再有，咱们认为 GC 的边际开销也是固定的。

注：这个「稳态」看起来有点不符合实际，然而他的确代表了在某种固定负载状况下的程序的行为状态。的确，在程序执行的时候负载也会是变动的，然而一个典型的程序，看起来像是一大堆稳固绑在一起的造成的刹时状态。

注：稳态没有对流动的堆内存做任何假如。堆可能会随着一系列 GC 周期而增长，可能会缩减，也可能放弃不变。要把这些状态全副涵盖的解释可能是简短乏味且难以描述的，因而本指南专一在堆内存放弃不变的场景。GOGC 那一节摸索了非固定堆内存场景的一些细节。

在这样的一个流动堆大小固定的场景下，只有是在固定的工夫距离后执行，每一个 GC 周期在模型中执行的花销上都是一样的。那是因为固定的工夫，固定的调配速度下，固定的堆内存会被调配。所以，因为流动堆内存和新增堆内存都是固定的，于是内存的应用也会永远一样。因为流动堆内存保持一致，边际带来的 GC CPU 开销也是固定的，于是在每一次惯例 (固定) 距离下执行的开销是固定的。

当初思考如果把 GC 执行点延后会怎么。那么更多的内存会被调配，然而每一个 GC 周期依然是应用雷同的 CPU 开销(译注：这里执行 GC 时候的边际 CPU 工夫应该会增大，可能并不显著)。那么随着的工夫窗口内，GC 周期将会更少，带来总的更少的 CPU 耗费。反之如果把 GC 执行点提前，会带来更少的内存被调配，和更多的 CPU 开销。

这个状况，通过管制 GC 执行的频度，正是最根本的在 CPU 工夫和内存调配之间的衡量。换句话说，这种衡量齐全取决于 GC 执行频率。

还残余一点须要确定，那就是什么时候 GC 决定执行。咱们留神到，在某种特定的稳态下，这个决定衡量的抉择，会间接失效在 GC 频率上。在 Go 语言中，用户次要管制的参数，就是决定执行 GC 的机会。

GOGC

参数 GOGC 在一个高维度上定义了 GC 时 CPU 和内存的衡量取舍。

它是通过在执行完一次 GC 周期之后，设置一个下次执行 GC 时的 指标堆大小 来实现工作的。GC 的指标是在总的堆大小超过指标堆大小之前执行一个收集周期。总的堆大小是应用上一个周期完结时候的流动堆内存大小来定义的，这个大小加上所有的自该周期完结后由程序动态分配的大小。指标堆大小定义如下：

指标堆大小 = 流动堆 + (流动堆 + GC roots) \times GOGC / 100

举一个例子，咱们有一个 Go 程序，它的流动堆大小为 8M，另外还有 1M 的 goroutine 栈，1M 的全局指针数据。那么，在 GOGC 被设置成 100 的时候，下一个 GC 周期开始之前，新调配的内存大小将会是 10MB，即 之前 (8M + 1M + 1M) 的 100%。总的堆大小脚印为 18M。如果 GOGC 设置为 50，那么（新调配的内存）就是 5M；如果 GOGC 是 200，那么这个值将会是 20M。

注：GOGC 从 Go 1.18 版本开始包含那些根内存大小。在此之前，它只会计算流动堆内存大小。一般来说，栈内存占比很小，堆内存占据了所有 GC 须要解决的内存的绝大部分，然而在某些有用成千上万个 goroutine 的状况下，GC 的计算值会不那么精确。

指标大小管制了 GC 频率，它被设置的越大，那么 GC 期待下一个周期的工夫就更长，反之亦然。准确的公式可能用于估算情况，不过 GOGC 更适合的是作为一个用来衡量 GC CPU 耗费和内存应用的参数。GOGC 值翻倍意味着 双倍的堆内存开销 ，也意味着 大抵减半的 GC CPU 开销，反之也是一样。（想要更全面的解释清参考本文附件）。

注: 指标堆大小仅仅是一个指标，有一些起因会导致 GC 周期并不是正好在此指标处实现。比方，一个足够大的堆内存调配就可能轻松超过此指标。同时，还有一些在具体的 GC 实现中呈现的相干起因，它们超出了本指南应用的模型。想要理解更多的细节，能够参考 提早(latency) 这一节，不过残缺的细节须要查阅这里的材料能够取得。

GOGC 能够通过配置环境变量设置（实用于所有的 Go 程序），也能够通过 runtime/debug 模块的 SetGCPercent 办法设置。

请注意 GOGC 这个参数是能够用来把整个 GC 敞开的（如果 memory limit 没有设置的话），能够通过 GOGC=off 或者 SetGCPercent(-1) 来操作。这相当于把 GOGC 设置为一个无限大的值，一个无奈达到的触发 GC 的新分配内存值。

为了让大家更好的了解，能够在上面尝试上面一个交互式可视展现，它是基于之前探讨的 GC 代价模型实现的。此展现程序描述了一个程序，它在无 GC 时会花掉 10 秒（CPU 工夫）执行。第一秒它会做一些初始化操作（流动内存减少），接下来进入稳态。整个程序会调配 200M 流动，其中 20M 是某一时刻下流动堆内存。这个程序假如所有的 GC 工作都只针对于流动堆内存，并且（不切实际的）假如程序不应用额定的内存。

译注：请大家务必去体验一下原文链接的带交互的展现程序，可能直观的感触到参数调节对于 GC 和 CPU 开销的意义。

应用滑块调整 GOGC 的大小，察看程序在总的工夫耗费和 GC 开销方面的反馈。每一个 GC 周期完结时新增堆降落为 0。新增堆降落为 0 的开销包含第 N 个周期的标记阶段开销和第 N + 1 个周期的革除阶段开销。留神这个可视化交互程序（包含本指南的其余可视化程序）假如在 GC 执行的时候整个程序是暂停的，所以 GC 的 CPU 开销齐全等同于它将新增堆大小减为 0 的工夫。这个只是为了简化可视化；然而对于直觉感触来说是实用的（译注：?）。X 轴的增长反映了总的 GC 带来的额定的 CPU 工夫的减少。

留神 GC 总是会带来一些 CPU 和峰值内存开销（的变动）。当 GOGC 减少的时候，CPU 开销降落，然而峰值内存绝对于流动堆成比例的减少。当 GOGC 减小时，峰值内存耗费缩小然而带来了一些额定的 CPU 开销。

注：（可视化程序）图表展现的是 CPU 工夫而非真实世界工夫。如果该程序跑在只有 1 个 CPU 的计算机并且应用全副的资源的状况下，二者是等价的。一个真实世界的程序往往是多核零碎，并且 Go 程序无奈在任何时候都利用 100% 的 CPU 资源。在这种状况下，GC 带来的实在工夫开销往往要比 CPU 工夫更低。

注：Go 语言 GC 有一个 4M 的最小堆内存大小，如果 GOGC 设置的目标值小于它的话，将会应用此值。咱们的可视化展现程序也遵循此细节执行。

接下来是一个更加动静和靠近实在的例子。和下面一样，在无 GC 状况，程序须要 10 秒 CPU 工夫执行，流动内存在开始阶段开始逐渐增长，并且稳态过程中急剧减少。该例子阐明了在稳态状况下流动堆是如何变动的，并且能够看到更高的增长率导致更加频繁的 GC 周期。

限度内存应用

在 Go 1.19 之前，GOGC 是惟一的能够调节 GC 行为的参数。尽管它在衡量（CPU 和内存）上工作良好，然而它没有思考到内存并不是无限大的因素。考虑一下如果咱们有一个流动内存的霎时峰值的状况：因为 GC 是依照总流动内存大小的成比例抉择的，GOGC 只能根据峰值流动内存确定，即使通常状况下更高的 GOGC 也提供了更好的衡量。

上面的例子阐明了刹时堆调配峰值带来的变动。

如果下面的示例程序工作在一个可用内存大略在 60M 多一点的容器中，那么 GOGC 就不能被调到比 100 更多（译注：会在峰值流动内存增长后耗尽内存），只管在后续的 GC 周期中有足够多的内存能够应用。而且，对于很多程序来说，刹时峰值可能很少呈现且难以预计，但它会造成偶尔的，无奈防止的可能会造成微小代价的 耗尽内存(out-of-memory) 情况。

这就是为何在 1.19 版本中，Go 减少了一个设置运行时应用内存的下限的形式。内存下限能够通过配置 GOMEMLIMIT 环境变量失效，或者调用 runtime/debug 库的 SetMemoryLimit 办法设置。

此参数设置了 Go 运行时可能应用的最大内存数量。具体设置的值，能够通过 runtime.MemStats 包外面的 mstats.Sys - mstats.HeapReleased 计算失去。

或者通过 runtime/metrics 包的 /memory/classes/total:bytes - /memory/classes/heap/released:bytes 形式获取。

因为 Go GC 零碎对于多少堆内存应用有清晰的掌控，它会基于设置的下限和 runtime 应用的内存量来设置总的堆内存大小。

上面的可视化展现程序和 GOGC 章节同样的稳态，然而减少了 10M 的额定 runtime 开销和能够一个能够调节的内存下限设置。尝试拉动 GOGC 和内存下限设置开关，看看会产生什么。

能够看到当内存下限被设置为低于峰值内存需要的时候（GOGC=100 的状况下峰值内存是 42M），为了放弃内存在限度范畴内，GC 会以十分高频的状态执行。

回到之前的有一个刹时峰值堆内存的例子，通过设置内存下限和调整 GOGC，咱们能够失去两败俱伤的状态：没有内存应用溢出 (breach) 和更好的资源使用率(译注：如下图，即在 GOGC = 100 的状况下，管制最大应用内存在 60M 以内)。尝试下方的可视化展现程序。

留意到在在某些 GOGC 和内存下限设置的状况下，峰值内存被限度管制住了，然而后续的程序仍旧遵循 GOGC 的设置的规定执行。

你可能观测到一个有意思的细节：就算 GOGC 敞开，内存下限依然是失效的。实际上这个配置代表着最大化资源利用率，因为它在内存下限的状况下设置了最低的 GC 执行频率。在示例中，每次程序的堆大小都涨到了设置的内存上限值处。

不过，即使内存下限是一个明确的无效工具，对于它的应用也不是没有代价的，它也无奈取代 GOGC。

想一下在流动内存增长到靠近内存下限下的状况。在下面的可视化程序中，敞开 GOGC，并且迟缓的缩小内存下限看看会产生什么。你会发现总的程序执行工夫会在某一时刻猛增，起因是为了遵循内存下限，GC 须要不停的执行。

在这种状态下，因为无限度的 GC 程序曾经无奈失常执行，这被叫做 抖动(Thrashing)。它十分的危险，因为此时程序被重大的拖慢。更坏的状况下，它会产生在咱们尝试应用 GOGC 来防止的最坏状况：一个很大的刹时对内存峰值导致程序陷入有限卡顿状态。把内存下限设置为 30M 或更低，看看霎时峰值导致的情况有多糟。

很多状况下，有限的卡顿会比内存耗尽更蹩脚，因为后者会导致更快的出错。

因而，内存下限被设计成 软限度。Go runtime 并不保障它肯定在所有状况下都维持内存下限；只是承诺肯定范畴的成果。放宽内存下限的限度对于避免抖动情况至关重要，因为它给了 GC 一个机会逃出去：让内存应用超过下限，避免在 GC 上划掉太多的工夫。

这在外部是通过为 GC 设置一个能应用更高的 CPU 工夫限度来实现的（会带来霎时的 CPU 峰值使用率）。这个限度目前是大概被设置为 50%，大概有 2 x GOMAXPROCS 秒 的 CPU 工夫窗口（译注：没看明确）。限度 GC 应用 CPU 工夫的起因是 GC 自身是延后执行的，同时程序可能依然在继续的调配新内存，甚至超过内存下限。

50% 的 GC CPU 应用是基于在内存足够的状况下一个程序受到的最坏冲击。在此状况下，一个被谬误的配的过低的内存下限，会导致程序最多被拖慢 2 倍，因为 GC 最多只可能占用 50% 的 CPU 工夫。

注：本文档的可视化程序并不模仿 GC 的 CPU 应用限度。

举荐用法

只管内存下限是一个有弱小的设置，而且 Go runtime 也在谬误应用的最坏状况做了弛缓操作，在应用时候你仍须要三思而行。上面是一些对于内存下限在哪些地方最有用、最实用，以及在哪些地方它可能弊大于利的倡议。

  • 在 Go 程序运行的环境齐全受你掌控时，并且在此 Go 程序是惟一的可能利用各种资源时（比方像一个预留了内存且限度了内存的容器），能够充分利用内存下限。

比方一个部署在固定内存大小的容器中 web 服务就是一个好例子。

在这种状况下，一种较好的教训法令是预留 5-10% 的内存给 Go runtime 无奈感知的中央。

  • 在理论运行的时候动静调整内存下限用于适配各种情况。

比方一个会调用 C 库调配大量内存的 cgo 程序。

  • 不要 在和其余程序共享无限内存的场景下敞开 GOGC，否则其余程序可能会被你的程序影响。相同，设置内存下限用来缓解峰值，并且设置更小，更正当的的 GOGC 用来解决惯例情况。

对于一个和其余程序合租内存空间的 Go 程序来说，尝试「预留」内存看起来挺有吸引力的，除非这些程序是齐全同步的（比方 Go 程序启动一些子过程，且在它们执行的时候阻塞），不然在所有程序都须要更多内存的时候会变得不可控。在 Go 程序不须要太多内存的时候尽量少实用一些会让整体更加牢靠。这项倡议在适度应用，即容器的内存下限之和大于理论物理内存的状况（译注：比方云主机超卖实例）也是实用的。

  • 不要 在你无法控制的状况下，特地是你的程序应用内存和输出相干的状况下应用内存下限。

比方一个 CLI 工具或者一个桌面利用。在你不晓得有哪些输出的状况下，或者你不晓得零碎有多少内存的状况下，内置一个内存下限在程序内会引起令人困惑的程序解体和性能问题。再说了，一个有教训的用户本人会依照需要设置适合的内存下限。

  • 当一个程序曾经快用完环境的内存的时候，不要 通过设置内存下限来防止内存耗尽。

这样的确能够无效的防止了内存耗尽，然而带来了程序变慢的危险，通常状况下这样并不划算，那怕 Go 本人会尝试缓解抖动。这种状况下，更好的做法是减少环境内存（再设置一个可能的内存限度）或者调小 GOGC（明确的 CPU 内存衡量胜过抖动缓解）。

提早（响应速度）

本文档提供的可视化程序模型在 GC 执行的之后暂停了程序的执行。理论的 GC 实现中的确存在这样的行为，他们被称作 “stop-the-world”（以下简称 stw）GC 操作。

实际上 Go GC 并不是齐全的 stw，大部分时候它都是和用户程序并发的执行的。（并发执行）次要是为了升高程序的提早。具体的说，提早指端到端的工夫距离（比方一个 web 申请）。到目前为止，本文档次要思考的是程序的吞吐量（比方在单位工夫内 web 申请的数量）。能够留神到在 GC 周期那一节的每个示例都专一于总的 CPU 执行时长。尽管这个时长对于一个 web 服务来说远没有那么重要。只管吞吐量对于一个 web 服务来说依然是很重要的（比方每秒查问次数），通常每一个独立申请的提早更加重要。

在提早方面，GC 的 标记和清理阶段都会产生较大的 stw 工夫，对于一个正在执行申请的 web 服务来说，此时申请会无奈执行。Go GC 竭力防止全局的 stw 工夫随着堆内存的增长而增长，并且防止在用户程序执行的时候执行外围的内存跟踪算法（这个 stw 在算发烧和 GOMAXPROCS 更相干，然而更决定性的是它进行执行的 goroutine 的工夫）。并发的收集并非是没有代价的，实际上它通常要比一个 stw 的垃圾收集器吞吐量更低。然而重要的是更低提早并不一定意味着更低的吞吐量，并且 Go 的垃圾回收器一直的在提早和吞吐两方面改良。

Go 并发执行的 GC 并不会是的咱们在前文的探讨变得无意义：下面的那些情景并不依赖具体设计的抉择。GC 的执行频率依然是 CPU 工夫和内存应用衡量的次要因子，并且它还在提早方面其次要因素。因为大部分 GC 的开销都在标记阶段被激活的时候产生。

要害的要点在于，升高 GC 频率可能导致 在提早响应方面的改善 。这就意味着不仅能够通过调试参数，通过减少 GOGC 值，并且(或者) 减少内存下限升高 GC 频率，而且能够通过这里的优化指南来优化。

不过提早通常要比吞吐量更加简单更加难懂，因为他是一个时刻产生的，不像吞吐量一下只是把开销加总。后果就是响应提早和 GC 执行频率并不是十分的间接。上面列出了一些可能的产生提早的起因供深刻思考钻研。

  1. 次要的 stw 暂停都是产生在标记和革除阶段的切换期内。
  2. 执行 GC 标记阶段最多会带来 25% 的 CPU 资源的应用。
  3. 在内存分配率很高的时候执行用户代码的 goroutine 会辅助执行 GC。
  4. 指针会带来 GC 标记阶段额定的开销。
  5. 扫描执行中的 goroutine 的 root 内存信息时候会挂起该 goroutine。

运行追踪器可能观测到除了指针带来的开销之外以上其余源的状态。

相干材料

只管上文的信息都是准确的，然而依然不足一个全面的对于 Go GC 计划带来的开销和衡量的理解。如果想理解更多的信息，请参考上面的资源：

  • The GC Handbook—对于 Go GC 的优良参考资料。
  • TCMalloc—C/C++ 的内存分配器 TCMalloc 的设计文档，Go 的分配器也是基于此。
  • Go 1.5 GC announcement—Go 1.5 版本的并行 GC 相干文章，形容了相干算法的细节。
  • Getting to Go—对于 Go GC 在 2018 年设计变革的深度展现。
  • Go 1.5 concurrent GC pacing—对于何时进行并发 GC 标记阶段的设计文档。
  • Smarter scavenging—订正 Go runtime 向 OS 偿还内存计划的设计文档。
  • Scalable page allocator—订正 Go runtime 向 OS 申请内存计划的设计文档。
  • GC pacer redesign (Go 1.18)—用于批改何时开始并发标记阶段的算法的设计文档。
  • Soft memory limit (Go 1.19)—软性内存下限的设计文档。

对于虚拟内存的阐明

本指南着重形容 GC 相干的物理内存的应用，一个随之而来的问题是，它意味着什么，虚拟内存相比又是怎么的（虚拟内存在 top 类的程序中显示为 VSS）。

物理内存是指在理论的 RAM 芯片中的内存。虚拟内存则是操作系统为每个不同的程序提供的对于物理内存的形象定义。通常状况下是答应程序预留实际上并未和任何物理地址映射 (map) 的虚拟地址。

因为虚拟内存仅仅只是一个由 OS 保护的映射关系，因而通常状况下预留一大片未映射到物理内存的虚拟内存的老本是极低的。

Go runtime 通常依赖这个低成本的虚拟内存，从以下几个方面：

  • Go runtime 不会删除它映射的虚拟内存。对应的，它应用一些 OS 提供的用于将指定虚拟内存相关联的物理内存开释的接口。
    此技术用与治理内存下限和把 Go runtime 不再应用的内存归还给 OS。Go runtime 也会在后盾不间断地把不实用的内存开释。对于此技术能够参考这里。
  • 32 位平台上 Go runtime 会预留 128M 到 512M 地址空间——在对的最后面，用于限度碎片化问题。
  • Go runtime 会预留大量的虚拟地址空间给外部数据结构。在 64 位平台上，最小的虚拟内存空间是大概 700M。在 32 位平台上则能够疏忽。

后果是，在 top 中看到的对于程序的 VSS 参数信息往往对于理解应用的内存空间意义不大，请把注意力放在 RSS或者相似的信息上，它能力实在的反馈物理内存应用状况。

优化指南

定位开销

在开始优化你的 Go 程序 GC 相干局部之前，先要确认 GC 是否是次要的开销。

Go 的技术生态中有不少用于定位开销和优化的工具。能够在诊断剖析指南 中大抵过一遍。咱们在这里次要关注和 GC 行为以及影响相干的一部分工具，并且依照一个更正当 (reasonable) 的程序介绍。

1. CPU profiles

CPU profiling 是最好的着手点。它提供了一个对于 CPU 开销的宏观展现，尽管不纯熟的话是很难通过它理解到程序中 GC 的占用的资源量级的。侥幸的是，能够通过对 runtime 包外面的不同函数的了解来归因 GC 的影响。上面是一组用于解释 CPU profile 很有用函数。

注：因为上面列出来的函数都不是最上层(leaf) 函数，因而他们可能不会在 pprof 工具的里应用的 top 指令就能展现进去。因而要应用 top -cum，或者间接用 list 函数名 查问这些函数的累计开销。

runtime.gcBgMarkWorker: 专门做 GC 标记工作的 goroutine 的入口函数。它耗费的工夫会随着 GC 频率、扫描的对象图的大小和复杂度的晋升而成比例进步。它展现了程序中有多少的工夫花在 GC 标记和扫描阶段。

注：对于一个大部分工夫都处于闲暇状态的 Go 程序，Go GC 会应用额定的（闲置）CPU 资源用来减速其执行。后果就是他可能占比很高，然而其实并无非凡意义。产生这种状况的常见起因：所有的逻辑在一个 goroutine 中实现，然而 GOMAXPROCS > 1（译注：Go 会应用不执行业务的其余 CPU 实现 GC，导致看起来 CPU 资源耗费较高）。

runtime.mallocgc: 堆内存分配器入口。如果它的累计耗费工夫 > 15%，往往意味着大量的内存调配。

runtime.gcAssistAlloc: 执行用户代码的 goroutine 把它的工夫片用来帮助 GC 执行扫描和标记的入口。如果累计耗费工夫 > 5%，示意程序在内存调配速度上超过了 GC。这通常意味着 GC 曾经带来了很高的冲击，它也会反映在程序花在 GC 标记和扫描的工夫上。
须要留神的是该函数在 runtime.mallocgc 中也会被执行，会导致它的占用工夫也膨胀起来。

2. Execution traces

只管 CPU profile 在对剖析（函数）累计开销上十分有用，它却在定位更加轻微、少见的性能开销以及响应速度相干用途较小。Execution traces 通过对 Go 程序执行时的一个较短窗口期，提供另一方面的，丰盛有深度的展现。它能够提供可视化的，对于 Go GC 相干的各种工夫，标记执行门路以及程序是如何与 GC 交互的。在 trace viewer 中能够查必定能到所有被失当地标记了的 GC 事件。

查看相干文档理解如何着手应用 execution traces。

3. GC traces

当其余计划生效时，Go GC 提供了一个特地的 trace 伎俩能够提供一些深刻的对 GC 行为做察看。这些 trace 伎俩通过启动的环境变量 GODEBUG 开启，间接在规范谬误输入 (STDERR) 打印，每一次 GC 周期输入一行。读懂他们须要对 GC 的实现有肯定理解，这也是次要用来调试 Go GC 自身的办法，不过有时候他们也会对你了解 GC 的行为有所帮忙。

外围的 GC trace 能够通过配置环境变量 GODEBUG=gctrace=1 开启。通过这项配置输入的内容能够在运行时的环境变量配置这一节查到。

一个叫做 调步追踪(pacer trace) 的，对于对于 GC trace 的补充 debug 信息能够通过设置环境变量 GODEBUG=gcpacertrace=1 开启。了解相干的输入信息须要对 GC 的调步算法（参考相干材料）有肯定理解，这些内容本指南不会波及。

缩小堆内存调配

间接缩小 GC 一开始治理的内存是一种升高 GC 开销的方法。上面形容的一些技术手段可能带来最大的性能收益，下面的 GOGC 章节曾经证实，Go 程序的堆内存分配率是影响本文认为的最大的开销：GC 频率的最大因子。

堆内存 profiling

在定位开销之后，接下来就是缩小堆内存最多调配的中央。为了达到此目标，内存 profile（实际上是堆内存 profile）十分的有用。浏览此文档获取上手信息。

内存 profile 形容了在程序中堆内存来自哪里，这是通过跟踪他们在执行栈上调配堆内存中央实现的。每一份对于内存的 profile 都能够把内存分为 4 类。

  • inuse_objects—流动内存对象数量
  • inuse_space—流动内存对象占据的内存字节大小
  • alloc_objects—Go 程序自启动后调配的内存对象总数量
  • alloc_space—Go 程序自启动后调配的内存对象总共占据的内存字节大小

要查看不同类别的堆内存信息，能够在应用 pprof 工具的时候用 -sample_index flag 参数，或者在交互式命令行工具下应用 sample_index 选项。

注：默认状况下内存 profile 工具只会采样一小部分堆内存对象，所以它们并不会蕴含所有的堆调配信息。不过这对于找到热点区域曾经足够了。能够尝试通过 runtime.MemProfileRate 调整采样率。

为了缩小 GC 开销，查看 alloc_space 通常是最无效的，因为它间接反映了内存分配率。察看这个信息可能获取到内存 调配热点，也代表优化的最大收益。

逃逸剖析

当咱们通过堆 profile 定位出了那些须要批改的堆内存分配器的之后，该如何打消这些调配呢？能够利用用 Go 编译器的逃逸剖析工具来找到更高效的寄存这些内存的中央，比方 goroutine 的栈空间。侥幸的是，Go 编译器能够形容一个 Go 的值为何被泄露到堆上。有了这个信息，就能够批改代码使得这个分析器的后果扭转（往往这是最艰难的一步，不过本指南并不波及这部分）。

As for how to access the information from the Go compiler’s escape analysis, the simplest way is through a debug flag supported by the Go compiler that describes all optimizations it applied or did not apply to some package in a text format. This includes whether or not values escape. Try the following command, where [package] is some Go package path.

那么如何取得 Go 编译器的逃逸剖析后果呢，最简略的办法是通过 Go 编译器反对的调试参数，它会生成对于指定包的所有优化信息到文本文件中，其中包含了值是否会逃逸的信息。尝试上面的命令，[package]指要剖析的包地址。

$ go build -gcflags=-m=3 [package]

This information can also be visualized as an overlay in VS Code. This overlay is configured and enabled in the VS Code Go plugin settings.
生成的信息也能够在 VS Code 中通过浮动层的形式展现。相干的配置和启用开关能够在 VS Code 的 Go 插件设置中管制。

  1. 开启 gc_details。
  2. 用 overlay 形式显示的逃逸剖析后果配置。

(译注：附录有我本人尝试的截图)

最初，Go 编译器还反对将这些信息输入到一个不便程序读取的格局(JSON) 中，后续可能会有一些额定的定制工具来解决。对于这部分能够参考源码中的文档。

Implementation-specific optimizations

Go GC 对于流动内存的关系图 (demographics) 特地明干，因为一个简单的兑现和指针关系图，既会限度并发度也会给 GC 产生更多的工作量。因而，存在一些为特定通用构造优化 GC 的形式。在上面列举了相干的最无效的优化计划。

注：依照上面的形式优化可能会因为其含混的用意而升高代码的可读性，而且可能会在新版本生效。仅当他们确实可能带来很大优化的时候应用。能够参考定位开销章节定位这些优化点。

  • 不蕴含指针的值是和其余值隔离解决的。
    于是，在不是必须的中央干掉指针会升高 GC 给程序带来的缓存压力(cache pressure)。后果是依赖下标而不是指针值的数据结构，只管不合理，确有着更好的性能。只有当你很分明对象图很简单且 GC 在标记和扫描时破费微小的时候才这么做。
  • GC 会在扫描一个值时，会在遇到最初一个指针之后完结。
    于是，把所有的指针成员放在构造体的最后方可能更优。只有当程序的确破费在对它的标记和扫描上很大是才值得去做。（实践上编译器应该主动这样做——指聚合指针在头部——然而还没有这样实现，目前构造体的成员还是依照他们在源码中的程序扫描的。）

此外，GC 会去和解决每一个它接触到的指针，因而应用一个 slice 的下标来代替指针会帮忙减小 GC 开销。

附录

对于 GOGC 的更多信息

（这一节很无聊且没有什么意义，省略了，读者能够自行浏览）

读后感

  • 这份文档形容的信息十分全，兴许它自身内容深度不太高，然而给出的参考文档都是十分有价值的。
  • 对于调参 GOGC 和 memory limit 的局部，感觉价值待商讨。
  • 整体来看，它构想的 Go 程序场景还是部署在云（或者容器）上的无状态 web 服务。对于咱们的场景（长时间运行的游戏服务器），有一些观点我认为是认可的，比方「卡顿不如 OOM」和「不该当 reserve 内存」等。
  • 用逃逸剖析来缩小堆内存调配的思路，是第一次见到。感觉很新鲜，可能对于无状态 web 申请的形式很有用（因为没有常驻逻辑和相干的内存援用，一次申请完之后所有资源回收，实践上能够做到大部分都在栈上分配内存）。
  • 翻译完了之后才发现他人曾经译过了，而且不止一个人……

附：
VS 中应用 GC 剖析工具:

退出移动版