.NET Core GC模式(gc mode)底层原理浅谈
简介CLR的GC模式与JVM的GC模式理念不同，相对JVM的各种小参显得比较简陋，CLR的理念是约定优于配置，并根据程序类型来分提供了几个默认的选项给大家选择。
[*]CS程序默认使用的工作站模式(WorkStation Mode)
[*]BS程序默认使用的服务器模式(Server Mode)
不同的模式，堆的默认大小也有不同。
但在.NET 8 之后，64位程序不管使用什么模式，都采用region管理法， 4M为一个segment。
https://learn.microsoft.com/en-us/dotnet/standard/garbage-collection/fundamentals
WorkStation Mode
工作站模式主要是为了满足基于UI的程序所需的响应性而设计的，因此意味着GC的停顿要尽可能的短。
为了实现GC少停顿，工作站模式有如下几个特征：
[*]只有一个托管堆
因为系统不可能只运行一个程序,每一个程序都会占用cpu与内存。因此多个堆反而会降低GC处理效率。从一开始工作站模式就被设定为只能由一个线程处理一个托管堆
[*]segment更小，GC触发频率更高
高频次的GC，会让GC的处理时间变短，因为对象变少了。GC需要做的准备工作也变少。用小步快跑的方式均衡因 gc 而暂停程序的时间
眼见为实
在WorkStation模式下，托管堆只有一个，且段空间很小(256M)
Server Mode
服务器模式是为了能满足处理并发请求的程序而设计的，这意味着它更看重吞吐量而不是GC停顿
为了平衡吞吐量与GC停顿，服务器模式有如下几个特征:
[*]堆的数量与CPU 核心数保持一致
大多数情况下，为了保证吞吐量，服务器只会部署一个程序，因此该程序基本上能“独享”整个CPU与内存。此时多个堆的并行处理能力比单个大堆处理更快。
[*]segment更大，GC频率相对降低
眼见为实
在 Server Mode下，托管堆数量与CPU保持一致，且段空间较大(1GB)
眼见为实：.NET 8 之后，统一采用region管理法， 4M为一个segment。
并发模式与非并发模式
从线程维度来看，GC还分为发模式与非并发模式。
[*]非并发模式
顾名思义，不能并发。在GC期间，所有托管线程都被暂停，待GC执行完后，再恢复线程的执行
[*]并发模式
顾名思义，支持并发。在GC期间，线程在特定情况下不会被暂停，从而提高吞吐量。
因此CLR提供的总共是2x2=4 ，4种GC模式供人选择。
JVM调优与CLR调优的差别
在JVM的世界中，JVM以GC为中心，提供了非常细颗粒度的配置让用户来自主选择，自由度非常高，但也需要非常了解参数背后的意义，上限很高的同时，下限也很低。
在CLR的世界中，CLR以Application为中心，提供4种模式让用户来自主选择，自由度相对较低，但提高了程序的下限。
举个例子： JVM是SSM，CLR是Spring Boot/Spring Cloud。 将开发人员从配置地狱中拉出来
由于C#支持值类型，因此优化方向主要在代码层面，而不是在CLR层面
CLR调优
虽然说约定大于配置，但也不是完全不能改。
CLR提供了少量参数，能让你调整堆数量，堆大小，是否启用并发GC等。
相对JVM来说，还是偏少。但是对比Framework，已经有了非常显著的进步。
https://docs.microsoft.com/en-us/dotnet/core/runtime-config/garbage-collector
CLR调优的重点是使用栈分配来降低堆分配，而不是调整堆配置。
JVM认为一切皆对象，因此绝大多数对象都分配在堆上，所以需要调整堆配置，来达到GC的平衡点。
非并发工作站模式
作为最简单的一种GC模式，前文已经介绍过，不再赘述。
[*]GC发生在用户线程上，没有额外的GC线程
[*]所有线程都被挂起
眼见为实：GC操作在调用它的线程上
4号线程触发了GC，GC操作直接在4号线程上运行。
眼见为实：其它线程也被暂停
可以看到，6号线程被“劫持”，进入了暂停状态。
202a0：通常表示线程正在运行或可运行状态。
2b220：可能表示线程处于等待状态，比如等待某个资源或事件。
非并发GC服务器模式
[*]相对WorkStation，最大的不同就是有专门的GC线程来处理，GC线程数与heap数一致，大多数情况下，它们被挂起以等待GC工作。
[*]所有回收都是非并发GC，多个GC线程并行回收，相对非并发工作站模式。STW的暂停时间要短得多。
[*]标记阶段也是多个GC线程并行完成，所以标记阶段的阻塞耗时也相对较短。
//用户线程触发GCGarbageCollectGeneration(){ //wake up an event ee_suspend_event.set(); wait_for_gc_done();}//gc线程：轮询处理gc_thread_function(){ while (1) { ee_suspend_event.Wait(); SuspendEE(); garbage_collect(); RestartEE(); }}garbage_collect(){ generation_to_condemn(); gc1();}gc1(){ mark_phase(); plan_phase();}plan_phase(){ // actual plan phase work to decide to // compact or not if (compact) { relocate_phase(); compact_phase(); } else make_free_lists();}眼见为实:GC线程数与Heap数一致
16核CPU，会创建16个Heap，从而创建16个GC 线程
眼见为实：GC发生在GC线程上
后台GC工作站模式
相对非并发工作站模式，后台GC使用一个单独的线程
前文讲到，如果GC决定压缩回收，因为要移动对象，所以这个时候STW是无法避免的，但如果GC决定标记清除，那就不一样了，完全可以做到托管线程不暂停或者少暂停来减少 STW 的时间，这就是后台GC要解决的问题。
简单来说，当FullGC决定标记清除时，后台GC可以让托管线程的绝大多数时间都处于可运行状态
因为临时回收速度很快，使用并发模式反而性能不高。因此只有在FullGC下才使用并发GC
//线程触发GC GarbageCollectGeneration() { SuspendEE(); garbage_collect(); RestartEE(); }//CLR 发现当前是fullgc 而且是标记清除，觉得有必要走bgc逻辑，接下来会生成 bgc 线程 garbage_collect() { generation_to_condemn(); // decide to do a background GC // wake up the background GC thread to do the work do_background_gc(); }//初始化 bgc 线程，通过 ee_proceed_event事件 激活 bgc 线程。 do_background_gc() { init_background_gc(); start_c_gc (); //wait until restarted by the BGC. wait_to_proceed(); }//bgc线程执行 gc1 函数，开始做 标记阶段 和 清扫阶段。 bgc_thread_function() { while (1) { // wait on an event // wake up gc1(); } } gc1() { //此时的mark_phase会进入二阶段暂停，而不是暂停所有线程 background_mark_phase(); //bgc在后台做标记清除，此时的托管线程在忙自己的活，处于一种并发状态 background_sweep(); }如何不干扰正常线程的同时，标记对象？
在正常情况下(STW),标记一个对象，可以利用MethodTable来写入额外信息，但在并发情况下，线程正在使用时，修改MethodTabl是非常危险的，因此并发标记将有关的信息存储在专用的标记数组中，由于GC是该数组的唯一写入/访问者，因此不会出现同步问题。
如何保持root根的一致性？mark_phase二阶段暂停
在并发模式下，之前被标记过的内存，也可能发生变化。此时需要重新标记发生变化的内存来确保无误。此时需要借助WriteWatch机制的来实现重新标记
WriteWatch类似卡表/卡表，只修改单个对象也会导致整个内存页失效。
mark_phase二阶段暂停大致分为如下几个步骤
[*]线程挂起期间，仅遍历线程栈与终结器的根，遍历完成后进入初始标记阶段
[*]通过restart_vm()恢复所有托管线程的运行状态，bgc线程继续提取根对象(句柄表)，进入并发标记阶段
[*]再次冻结线程，通过WriteWatch，又回过头重新扫描被修改的内存，进入最终标记阶段
[*]再次恢复托管线程，bgc在后台完成Free标记
眼见为实：初始标记阶段，GC线程处于SuspendEE
点击查看代码 internal class Program { static void Main(string[] args) { Debugger.Break(); Alloc(); Console.ReadLine(); } static List<string> list = new List<string>(); static Random rand = new Random(); static void Alloc() { for (int i = 0; i < int.MaxValue; i++) { list.Add(string.Join(",", Enumerable.Range(1, 1000))); if (i > 100) { list = null; } } } }使用bp coreclr!WKS::gc_heap::background_mark_phase 下断点
主线程触发GC，触发了SuspendEE
眼见为实：并发标记阶段，托管线程处于正常状态
使用bp coreclr!WKS::gc_heap::revisit_written_pages 下断点
主线程正常运行，移除了触发线程SuspendEE的标记
眼见为实：最终标记阶段，托管线程处于SuspendEE
使用bp coreclr!WKS::gc_heap::background_sweep 下断点
GC线程又触发了SuspendEE，实现最终标记。
其它线程被暂停
眼见为实：清扫阶段，又将托管线程解冻
使用bp coreclr!WKS::gc_heap::compute_new_dynamic_data 下断点
SuspendEE标记又被清除
其它线程恢复正常运行
后台GC服务器模式
此GC模式是最复杂的一种，但有了前三种GC模式的铺垫，相信你已经摸清了它的套路。
与后台工作站模式类似，但不同的是
[*]每个托管堆有两个专门用于GC的线程
1.1 一个是服务器GC线程，负责执行堆中阻塞式GC，对应gc_thread_function函数
1.2 一个是后台GC线程，负责执行堆中后台式GC，对应bgc_thread_function函数
0，1代等临时回收使用阻塞式GC，因为临时回收速度足够快
FULLGC根据实际情况采用后台GC或者阻塞式GC
GarbageCollectGeneration(){ //wake up an event ee_suspend_event.set(); wait_for_gc_done();}gc_thread_function(){ while (1) { ee_suspend_event.Wait(); SuspendEE(); garbage_collect(); RestartEE(); }}garbage_collect(){ generation_to_condemn(); // decide to do a background GC // wake up the background GC thread to do the work do_background_gc();}do_background_gc(){ init_background_gc(); start_c_gc(); //wait until restarted by the BGC. wait_to_proceed();}bgc_thread_function(){ while (1) { bgc_start_event.Wait(); gc1(); }}gc1(){ background_mark_phase(); background_sweep();}眼见为实
LowLatencyGC
除了以上4种GC模式外，还可以代码来设置延迟模式，来控制GC导致的阻塞频次。
// // 摘要: // Adjusts the time that the garbage collector intrudes in your application. public enum GCLatencyMode { // // 摘要: // Disables garbage collection concurrency and reclaims objects in a batch call. // This is the most intrusive mode. This mode is designed for maximum throughput // at the expense of responsiveness. //该模式下，垃圾回收器以批量方式工作，尽可能提高吞吐量。 //在这种模式下，垃圾回收器会等待更多的内存被分配后才进行回收操作，以减少垃圾回收的频率，从而提高应用程序的整体吞吐量。不过，这可能会导致较长的垃圾回收停顿时间 //适用于对响应时间要求不高，但对吞吐量有较高要求的应用程序，例如批量数据处理任务、长时间运行的后台作业等。这些应用可以容忍较长的垃圾回收停顿，因为它们主要关注的是在单位时间内处理更多的数据。 Batch = 0, // // 摘要: // Enables garbage collection concurrency and reclaims objects while the application // is running. This is the default mode for garbage collection on a workstation // and is less intrusive than System.Runtime.GCLatencyMode.Batch. It balances responsiveness // with throughput. This mode is equivalent to garbage collection on a workstation // that is concurrent. //这是默认的垃圾回收模式。它在吞吐量和响应时间之间进行了平衡，允许垃圾回收器在应用程序运行过程中进行并发的垃圾回收操作，以减少应用程序的停顿时间。 //在这种模式下，垃圾回收器会更频繁地进行小规模的回收操作，从而保持应用程序的响应性。 //适用于大多数交互式应用程序，如桌面应用程序、Web 应用程序等。这些应用需要及时响应用户的操作，因此不能容忍过长的垃圾回收停顿时间。 Interactive = 1, // // 摘要: // Enables garbage collection that is more conservative in reclaiming objects. Full // collections occur only if the system is under memory pressure, whereas generation // 0 and generation 1 collections might occur more frequently. This mode is not // available for the server garbage collector. //该模式着重于减少垃圾回收的停顿时间，以提供低延迟的响应。垃圾回收器会更频繁地进行小规模的回收操作，并且会尽量避免长时间的 “STW” 停顿。 //不过，这种模式可能会降低应用程序的吞吐量，因为垃圾回收操作会更频繁地打断应用程序的执行。 //适用于对延迟非常敏感的应用程序，如实时游戏、金融交易系统等。这些应用需要在短时间内对用户输入或外部事件做出响应，因此对垃圾回收的停顿时间有严格的要求 LowLatency = 2, // // 摘要: // Enables garbage collection that tries to minimize latency over an extended period. // The collector tries to perform only generation 0, generation 1, and concurrent // generation 2 collections. Full blocking collections may still occur if the system // is under memory pressure. //此模式旨在提供持续的低延迟性能，尤其适用于需要长时间保持低延迟的应用场景。与 LowLatency 模式相比，SustainedLowLatency 模式会更加保守地进行垃圾回收，尽量避免触发可能导致长时间停顿的大型垃圾回收操作。 //不过，这也可能会导致内存使用量逐渐增加，因为垃圾回收器不会及时回收所有的垃圾对象。 //用于需要长时间保持低延迟的应用程序，如高频交易系统、实时数据分析系统等。这些应用在长时间运行过程中都需要快速响应，不能容忍明显的垃圾回收停顿。 SustainedLowLatency = 3, // // 摘要: // Indicates that garbage collection is suspended while the app is executing a critical // path. System.Runtime.GCLatencyMode.NoGCRegion is a read-only value; that is, // you cannot assign the System.Runtime.GCLatencyMode.NoGCRegion value to the System.Runtime.GCSettings.LatencyMode // property. You specify the no GC region latency mode by calling the Overload:System.GC.TryStartNoGCRegion // method and terminate it by calling the System.GC.EndNoGCRegion method. // 迄今为止可以设置的最强p配置，只要内存足够，该模式会在代码执行期间尝试禁止垃圾回收， NoGCRegion = 4 }眼见为实
举个例子1：
static void Main() { // 设置垃圾回收模式为 LowLatency System.GC.LatencyMode = System.Runtime.GCLatencyMode.LowLatency; // 模拟一些工作 for (int i = 0; i < 1000000; i++) { // 创建一些对象 var obj = new byte; Thread.Sleep(1); } // 恢复默认的垃圾回收模式 System.GC.LatencyMode = System.Runtime.GCLatencyMode.Interactive; }举个例子2：
using System;using System.Runtime;class Program{ static void Main() { // 创建一个无垃圾回收区域 using (NoGCRegion noGC = new NoGCRegion(NoGCRegionOptions.BestEffort)) { // 在这个代码块内，尽量避免进行完整的垃圾回收 // 执行对延迟敏感的操作，例如处理高频交易订单 for (int i = 0; i < 1000; i++) { // 模拟一些对延迟敏感的工作 Console.WriteLine($"Processing item {i}"); } } // 离开无垃圾回收区域后，垃圾回收器恢复正常工作 }}https://www.cnblogs.com/cdaniu/p/15927791.html
https://learn.microsoft.com/zh-cn/dotnet/api/system.runtime.gclatencymode?view=net-9.0
总结
GC 模式目标场景特点适用场景Workstation GC客户端应用低延迟，单线程或并发桌面应用、UI 应用Server GC服务器应用高吞吐量，多线程ASP.NET、Web API 等服务器应用Background GC低延迟 + 高吞吐量允许后台回收，减少停顿对延迟敏感的服务器或客户端应用SustainedLowLatency极低延迟避免完全垃圾回收，减少停顿实时系统、游戏、金融交易系统https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/garbage-collection.md
页:
[1]