.NET GC工作流程

前言

在上文[如何获取GC的STW时间]一文中，我们聊到了如何通过监听GC发出的诊断事件来计算STW时间。里面只简单的介绍了几种GC事件和它的流程。

群里就有小伙伴在问，那么GC事件是什么时候产生的？分别是代表什么含义？

那么在本文就通过几个图为大家解答一下这个问题。

有哪些GC模式？

工作站和服务器模式

在.NET中，GC其实有一些不同的工作模式，根据客户端和服务器可以分为如下两种模式：

Workstation GC

Workstation GC（工作站GC），这种模式主要是为了满足基于UI的交互式应用程序设计的，交互式意味着GC的暂停时间要尽可能的短。因为我们不想因为触发GC导致较长的GC停顿。

GC会更频繁的发生，每次暂停时间都会很短。
内存占用率更低，因为GC更频繁的发生，所以内存回收的更积极，占用率也会更低。
无论是否有配置多CPU核心，垃圾回收始终只使用一个CPU核心，只有一个托管堆。
内存段的大小设置会很小。

Server GC

Server GC （服务器GC），这种模式主要是为了满足基于请求处理的WEB等类型应用程序设计的，这意味着它更侧重于需要满足大的吞吐量，零星的停顿不会对齐产生重大的影响。

GC的发生频率会降低，优先满足大吞吐量。
内存占用率会更高，因为GC发生的频率变低，内存中可能会有很多垃圾对象。
垃圾回收使用高优先级运行在多个专用线程上。每个CPU核心都提供执行垃圾回收的专用线程和堆，每个CPU核心上的堆都包含小对象、大对象堆。
因为多个垃圾回收线程一起工作，所以对于相同大小的堆，Server GC会回收的更快一些。
服务器垃圾回收通常会有更大的Segment，另外也会占用更多的资源。

并发与非并发模式

另外根据GC相对于用户线程的操作方式，还可以分为下面两种方式：

Non-Concurrent

Non-Concurrent（非并发GC），这种方式是一直存在于.NET中的，它适用于工作站和服务器模式，在GC进行过程中，所有的用户线程都会挂起。

Concurrent（已过时）

Concurrent （并发GC），并发GC模式它和用户线程同时工作，GC进行过程中只有少数几个过程需要挂起用户线程。所以它的实现也更加复杂，但是暂停时间会更短，性能也会更好，不过现在它已经过时，本文不会着重描述它。

Background

Background（后台GC），在.NET Framework 4.0以后，后台GC取代了并发GC，它只适用于Gen2的回收，但是它可以触发对于Gen0、Gen1的回收。根据WorkstationGC和ServerGC的模式会分别在一个或多个线程上执行。

GC工作流程

需要知道的GC事件

其实对于我们分析GC的工作来说，上文中提到的几个事件已经足够使用了，让我们再来回顾一下这些事件。

Microsoft-Windows-DotNETRuntime/GC/SuspendEEStart	//开始暂停托管线程运行

Microsoft-Windows-DotNETRuntime/GC/SuspendEEStop	//暂停托管线程完成

Microsoft-Windows-DotNETRuntime/GC/Start	// GC开始回收

Microsoft-Windows-DotNETRuntime/GC/Stop		// GC回收结束

Microsoft-Windows-DotNETRuntime/GC/RestartEEStart	//恢复之前暂停的托管线程

Microsoft-Windows-DotNETRuntime/GC/RestartEEStop	//恢复托管线程运行完成

图例

为了让大家能更清晰的看懂下面的图，会用不同形状和颜色的图像来代表不同的含义，如下方所示：

绿色：正在运行的用户线程。

红色：执行引擎进行线程冻结或线程恢复。

实线箭头：正在运行的GC线程。

虚线箭头：被暂停的线程。

黄色圆球：GC事件。

红色圆球：标记点。

WorkstationGC模式-非后台(并发)GC

下图是WorkStationGC（非后台）模式的执行流程，我们假设它是在一个双核的机器上运行（下文中都是假设在双核机器上运行），运行过程其实就像下图所示。

在上图中的事件流如下所示：

GC/SuspendEEStart

GC/SuspendEEStop

GC/Start

GC/Stop

GC/RestartEEStart

GC/RestartEEStop

其中各个标记点分别完成了如下工作：

A->B：暂停所有用户线程
B->C: 挑选一个用户线程作为GC线程，然后开始进行垃圾回收
- 选择-需要被回收的一代
- 标记-被回收的一代和更年轻一代对象
- 计划-GC决定是需要压缩整理堆还是只是清扫堆就够了
- 清扫、搬迁和压缩-根据上面计划的结果，执行清扫堆，或者搬迁活着的对象然后整理堆，最后所有对象的地址更新到新地址。
C->D: GC工作结束，恢复线程运行

由于GC暂停了所有的线程，所以A->D就是此类GC的STW Time时间。

ServerGC模式-非后台(并发)GC

下图是ServerGC（非后台）模式的执行流程。

它与WorkstationGC模式的事件流和完成的工作都一致，唯一不同的就是它会根据当前的CPU逻辑核心数量创建单独的GC线程，比如上图就有2个GC线程。

另外在服务器GC模式中，用户线程还是可以作为GC线程来使用的，像用户线程1在GC发生的时候就做了一些GC工作。

WorkstationGC模式-后台GC

下图是WorkstationGC（后台）模式的执行流程，可以看到后台模式还是相当复杂的，会短暂的暂停多次，每一次都会执行不同的操作。

除了工作线程GC以外，另外会有单独的后台GC线程进行后台垃圾回收。

上图中的事件流如下所示：

GC/SuspendEEStart

GC/SuspendEEStop

GC/Start

GC/RestartEEStart

GC/RestartEEStop

GC/SuspendEEStart

GC/SuspendEEStop

GC/RestartEEStart

GC/RestartEEStop

GC/SuspendEEStart

GC/SuspendEEStop

GC/Start

GC/Stop

GC/RestartEEStart

GC/RestartEEStop

GC/Stop

其中各个标记点完成的工作如下所示：

A->B：初始选择、标记
- 此时用户线程是暂停的
- 选择需要被回收的一代
- 找到GC roots，以便并发标记
B->C：并发标记
- 此时用户线程是正常运行的
- 从上一步中找到的GC roots开始标记需要被回收的一代和年轻的代
D->E：最终标记
- 此时用户线程是暂停的
- 扫描在并发标记过页面，看看是否有修改让对象重新活过来的
F->G：清扫小对象堆
- 此时用户线程是正常运行的
- 清扫小对象堆的对象
H->I：压缩整理小对象堆、清扫压缩整理大对象堆
- 此时用户线程是暂停的
- 选择了一个用户线程进行GC
- 用来压缩小对象堆的对象
- 另外也会压缩和整理大对象堆对象
J->K：清扫大对象堆
- 此时用户线程是正常运行的
- 此时会清扫和整理大的对象堆
- 此时会禁止分配大对象，阻塞对应线程直到大对象堆回收完成

从上面的的流程中可以看到，后台GC主要是通过并发+多次短暂暂停来实现提升吞吐量和降低总体的STW Time的，其内部实现是非常复杂的，有兴趣的小伙伴可以直接看dotnet/runtime/gc.cpp文件。

ServerGC模式-非后台GC

下图是ServerGC（后台）模式的执行流程。

它与WorkstationGC模式的事件流和完成的工作都一致，唯一不同的就是它会根据当前的CPU逻辑核心数量创建单独的GC线程，比如上图就有2个GC线程，2个后台GC线程。

总结

今天带了解了一下.NET GC中的各个阶段和事件的顺序，当然这里只是简单的带大家了解一下，要知道在任何有runtime的平台中，GC是其中相当关键的东西，大家如果对GC感兴趣，可以阅读附录中的资料。

附录