当前位置：首页 > news >正文

C# 垃圾回收机制深度解析

news 2025/11/11 8:27:43

C# 垃圾回收机制深度解析

引言

C#的垃圾回收（GC）是.NET运行时最核心的特性之一。很多开发者对GC的理解停留在"自动管理内存"这个层面，但实际上，深入理解GC的工作机制对于编写高性能应用至关重要。本文将从原理到实践，系统性地讲解GC的方方面面。

一、GC的核心原理

1.1 为什么需要GC

在C/C++中，程序员需要手动调用malloc/free或new/delete来管理内存。这种方式带来两个严重问题：

内存泄漏：忘记释放内存，导致可用内存逐渐减少
野指针：访问已释放的内存，导致程序崩溃或安全漏洞

C#的GC通过自动追踪对象引用，在对象不再被使用时自动回收内存，从根本上解决了这两个问题。但自动化是有代价的——GC需要暂停程序执行来进行垃圾回收，这就是所谓的"STW（Stop-The-World）"暂停。

1.2 托管堆的内存分配

当你写下 var obj = new MyClass() 时，发生了什么？

CLR会在托管堆上为对象分配内存。与C++的堆分配不同，.NET的堆分配非常快速——几乎和栈分配一样快。原因在于.NET使用了一个简单但高效的策略：

// 伪代码展示分配过程
void* AllocateObject(size_t size) {if (nextObjPtr + size > heapLimit) {TriggerGC();  // 空间不足，触发GC}void* obj = nextObjPtr;nextObjPtr += size;  // 指针简单移动return obj;
}

托管堆像一个连续的内存块，每次分配就是把指针往后移动。这种"指针碰撞（Bump Pointer）"的方式使得分配操作只需要几条CPU指令，非常高效。

但这带来一个问题：如果不断分配对象，堆很快就会耗尽。这就需要GC定期回收不再使用的对象，并压缩内存，让指针可以重新从前面开始分配。

1.3 如何判断对象可以回收

GC的核心算法是可达性分析。简单来说，GC会从一组"根引用"出发，追踪所有能访问到的对象。那些追踪不到的对象就是垃圾。

根引用包括：

静态字段引用的对象
线程栈上的局部变量
CPU寄存器中的引用
GC Handle（固定对象的句柄）
终结队列中的对象

看一个实际例子：

public class DataProcessor {private static List<byte[]> cache = new List<byte[]>();  // 根：静态字段public void Process() {var buffer = new byte[1024];  // 根：局部变量var temp = new byte[512];     // 根：局部变量cache.Add(buffer);  // buffer被静态字段引用，方法结束后仍不会被回收// temp没有被任何根引用，方法结束后会被回收}
}

在这个例子中，buffer因为被添加到静态列表中，所以会一直存活。而temp在方法结束后就没有任何引用了，会在下次GC时被回收。

1.4 标记-清除-压缩算法

GC的回收过程分为三个阶段：

标记阶段（Mark）

从根引用开始，递归遍历对象图，给所有可达对象打上标记：

void MarkPhase() {// 遍历所有根引用foreach (var root in GetRootReferences()) {MarkObject(root);}
}void MarkObject(object obj) {if (obj == null || obj.IsMarked) return;obj.IsMarked = true;  // 打上标记// 递归标记所有引用的对象foreach (var reference in obj.GetAllReferences()) {MarkObject(reference);}
}

清除阶段（Sweep）

遍历堆，回收所有未标记的对象。

压缩阶段（Compact）

这是.NET GC与很多其他GC实现的关键区别。压缩阶段会移动所有存活的对象，使它们在内存中连续排列：

回收前：[Obj1][垃圾][Obj2][垃圾][垃圾][Obj3]
回收后：[Obj1][Obj2][Obj3][___空闲空间___]

压缩的好处显而易见：

消除内存碎片，避免"有空间但分配不了"的问题
提高缓存命中率，因为相关对象在内存中相邻
让后续分配可以继续使用高效的指针碰撞方式

但压缩也有代价：需要更新所有指向被移动对象的引用，这需要时间。

二、分代回收机制

2.1 为什么要分代

如果每次GC都扫描整个堆，代价会非常高。微软的研究人员发现了一个关键规律：

大多数对象在创建后很快就会死亡，只有少数对象会长期存活

基于这个"分代假说"，.NET GC将对象分为三代：

Gen 0：新分配的对象，大小通常只有几MB
Gen 1：经历过一次GC仍存活的对象，起到缓冲作用
Gen 2：经历过多次GC的老对象，可能占据几GB甚至更多

这种设计的精妙之处在于：大部分时候GC只需要回收Gen 0，这只需要扫描几MB的内存，耗时可能只有几毫秒。而完整的Gen 2回收（Full GC）可能需要几百毫秒甚至更久。

2.2 代的晋升机制

对象的生命周期就像是一个晋升系统：

var obj = new MyClass();  // 创建在Gen 0// 第一次GC触发，obj存活
// obj晋升到Gen 1// 第二次包含Gen 1的GC触发，obj存活
// obj晋升到Gen 2// 之后obj一直待在Gen 2，除非被回收

这意味着，如果你的对象生命周期很长（比如全局缓存），它们最终都会进入Gen 2。而Gen 2回收的频率很低，这就带来一个问题：如果Gen 2里堆积了大量其实应该回收的对象，内存占用会居高不下。

2.3 跨代引用问题

分代回收有一个技术难题：如果只扫描Gen 0，怎么知道Gen 2中的对象有没有引用Gen 0的对象？

比如：

public class OldObject {  // 在Gen 2中public NewObject reference;  // 指向Gen 0对象
}// 如果只扫描Gen 0，会误认为NewObject是垃圾

解决方案是写屏障（Write Barrier）。每当一个老代对象被修改为引用新代对象时，JIT编译器会插入额外的代码，记录这个跨代引用：

// 源代码
oldObj.field = newObj;// 实际执行的代码（简化）
oldObj.field = newObj;
if (GetGeneration(oldObj) > GetGeneration(newObj)) {RecordCrossGenerationReference(oldObj);
}

这样，在回收Gen 0时，GC只需要检查这个记录表，就知道哪些Gen 2对象引用了Gen 0对象，无需扫描整个Gen 2。

2.4 实际运行特征

让我们看看一个真实应用的GC行为：

public class GCMonitor {public static void PrintGCStats() {Console.WriteLine($"Gen 0: {GC.CollectionCount(0)} 次");Console.WriteLine($"Gen 1: {GC.CollectionCount(1)} 次");Console.WriteLine($"Gen 2: {GC.CollectionCount(2)} 次");}
}// 运行一个Web应用一小时后
// 可能看到：
// Gen 0: 35000 次
// Gen 1: 1200 次
// Gen 2: 15 次

这个数据很直观地展示了分代回收的效果：Gen 0回收非常频繁但很快，Gen 2回收很少但可能导致明显的延迟。

三、GC的触发时机

3.1 自动触发

GC的触发主要由以下几个因素决定：

1. Gen 0达到阈值

这是最常见的触发条件。Gen 0的阈值是动态调整的，通常在几MB到几十MB之间。CLR会根据应用程序的行为调整这个阈值：

如果Gen 0回收效率很高（回收了大量垃圾），CLR会增大阈值，减少GC频率
如果回收效率低（大部分对象都存活），CLR会减小阈值

2. 系统内存压力

当操作系统通知.NET进程内存紧张时，GC会主动触发回收。这种情况在容器环境中特别常见，因为容器通常有严格的内存限制。

3. 显式调用

GC.Collect() 会强制触发GC。但在绝大多数情况下，你不应该调用它。CLR的GC调度算法经过高度优化，通常比手动调用更合理。

唯一合理的使用场景：

// 应用程序刚完成一个大型操作，知道接下来会有一段空闲期
public void AfterLargeOperation() {// 处理了大量数据，现在要进入等待状态GC.Collect(2, GCCollectionMode.Optimized);GC.WaitForPendingFinalizers();GC.Collect();
}

3.2 GC的暂停时间

GC暂停是性能优化的关键关注点。不同代的回收，暂停时间差异巨大：

Gen 0回收：通常1-10毫秒
Gen 1回收：通常10-50毫秒
Gen 2回收（Full GC）：可能几百毫秒到数秒

对于交互式应用（桌面程序、游戏），即使10毫秒的暂停也可能导致可察觉的卡顿。对于服务器应用，数百毫秒的暂停可能导致请求超时。

四、GC模式详解

4.1 工作站GC vs 服务器GC

这是.NET提供的两种根本不同的GC模式：

工作站GC（Workstation GC）

单独的GC线程
针对低延迟优化
适合客户端应用

服务器GC（Server GC）

每个CPU核心对应一个GC线程和一个堆
针对吞吐量优化
适合服务器应用

一个关键的区别：在服务器GC中，每个CPU核心有自己的堆。比如在8核机器上，会有8个独立的Gen 0/1/2堆。对象分配时，根据线程所在的CPU核心，分配到对应的堆上。

这种设计的好处：

减少线程竞争，因为每个线程倾向于在自己的堆上分配
GC时可以并行处理，充分利用多核性能

代价是：

内存占用更多（每个堆都有overhead）
暂停时间可能更长（虽然吞吐量更高）

配置方式：

<!-- 在 .csproj 中 -->
<PropertyGroup><ServerGarbageCollection>true</ServerGarbageCollection>
</PropertyGroup>

或运行时检查：

bool isServerGC = GCSettings.IsServerGC;
Console.WriteLine($"当前GC模式: {(isServerGC ? "服务器" : "工作站")}");

4.2 并发GC与后台GC

并发GC（.NET Framework 4.0之前）和后台GC（.NET 4.0+）都是为了减少暂停时间。

核心思想是：Gen 2回收可以和应用程序并发执行。虽然标记阶段仍需要短暂暂停，但大部分工作可以在后台完成。

时间线：
|----- 应用运行 -----|-- 暂停 --|--- 应用运行 ------|-- 暂停 --|--- 应用运行 -----|标记开始      后台标记进行中       标记结束

后台GC的一个重要改进：即使Gen 2回收正在后台进行，Gen 0和Gen 1的回收仍然可以在前台触发。这进一步减少了延迟。

4.3 低延迟模式

对于时延敏感的场景，可以临时切换到低延迟模式：

public void TimeStensitiveOperation() {GCLatencyMode oldMode = GCSettings.LatencyMode;try {GCSettings.LatencyMode = GCLatencyMode.SustainedLowLatency;// 执行对延迟敏感的代码// 这期间GC会尽量避免Full GCPerformCriticalTask();}finally {GCSettings.LatencyMode = oldMode;}
}

SustainedLowLatency模式会推迟Gen 2回收，但如果内存确实不足，仍然会触发。这不是"禁用GC"，而是调整GC的策略。

.NET Core 2.0还引入了NoGCRegion API：

if (GC.TryStartNoGCRegion(1024 * 1024 * 10)) {  // 10MBtry {// 这个区域内保证不会GC// 但必须确保分配不超过指定大小PerformCriticalTask();}finally {GC.EndNoGCRegion();}
}

五、大对象堆（LOH）

5.1 什么是大对象

在.NET中，大小≥85,000字节的对象被视为"大对象"，分配在大对象堆（Large Object Heap, LOH）上。

为什么是85KB这个神奇的数字？因为Gen 0的典型大小在几MB，如果允许超大对象进入Gen 0，可能导致频繁的内存移动。

byte[] small = new byte[84999];  // 普通对象堆
byte[] large = new byte[85000];  // 大对象堆（LOH）

5.2 LOH的特殊之处

LOH与普通堆有几个重要区别：

1. 默认不压缩

移动一个100MB的对象代价太高，所以LOH默认只清除，不压缩。这会导致内存碎片：

[100MB对象][空闲50MB][80MB对象][空闲30MB]

如果现在需要分配一个60MB的对象，即使总共有80MB空闲空间，也无法分配，因为没有连续的60MB。

2. 直接分配在Gen 2

大对象不经过Gen 0/1，直接进入Gen 2。这意味着它们只在Full GC时才会被回收。

3. 可以启用压缩

.NET 4.5.1引入了按需压缩LOH的能力：

// 下次Full GC时压缩LOH
GCSettings.LargeObjectHeapCompactionMode =GCLargeObjectHeapCompactionMode.CompactOnce;GC.Collect();

5.3 LOH导致的性能问题

案例1：频繁分配大对象

// 糟糕的代码
public byte[] ProcessImage(Image img) {byte[] buffer = new byte[10 * 1024 * 1024];  // 每次都分配10MB// 处理图片return result;
}// 如果这个方法被频繁调用，会导致：
// 1. LOH快速增长
// 2. 频繁触发Full GC
// 3. 可能出现LOH碎片

优化方案：使用ArrayPool

public byte[] ProcessImage(Image img) {var pool = ArrayPool<byte>.Shared;byte[] buffer = pool.Rent(10 * 1024 * 1024);try {// 处理图片return result;}finally {pool.Return(buffer);}
}

ArrayPool维护了一个数组池，Rent和Return只是从池中取出和归还，避免了实际的内存分配。

案例2：LOH碎片导致OutOfMemoryException

// 实际可用内存充足，但由于碎片无法分配
List<byte[]> list = new List<byte[]>();// 交替分配不同大小的数组
for (int i = 0; i < 100; i++) {list.Add(new byte[10 * 1024 * 1024]);  // 10MBlist.Add(new byte[5 * 1024 * 1024]);   // 5MB
}// 删除所有10MB的数组
for (int i = 0; i < list.Count; i += 2) {list[i] = null;
}GC.Collect();// 此时LOH布局：[空10MB][5MB][空10MB][5MB]...
// 尝试分配20MB会失败，尽管空闲空间总共有500MB
byte[] hugeArray = new byte[20 * 1024 * 1024];  // 可能抛出OutOfMemoryException

六、终结器与Dispose模式

6.1 终结器的问题

C#允许定义终结器（析构函数）来清理非托管资源：

public class FileWrapper {private IntPtr fileHandle;~FileWrapper() {// 关闭文件句柄CloseHandle(fileHandle);}
}

但终结器有严重的性能问题：

1. 延长对象生命周期

有终结器的对象需要至少两次GC才能回收：

第一次GC：发现对象不可达 → 放入终结队列
终结器线程：执行~FileWrapper()
第二次GC：真正回收内存

这期间对象会被提升到更高代，可能在内存中停留很久。

2. 终结器线程是单线程的

所有终结器在一个专门的线程上顺序执行。如果某个终结器执行缓慢（比如网络IO），会阻塞其他对象的终结。

3. 执行时机不确定

你无法控制终结器何时执行，甚至程序退出时可能不执行。

6.2 正确的Dispose模式

推荐的做法是实现IDisposable接口：

public class ResourceHolder : IDisposable {private IntPtr unmanagedResource;private Stream managedResource;private bool disposed = false;public void Dispose() {Dispose(true);GC.SuppressFinalize(this);  // 告诉GC不需要调用终结器}protected virtual void Dispose(bool disposing) {if (disposed) return;if (disposing) {// 释放托管资源managedResource?.Dispose();}// 释放非托管资源if (unmanagedResource != IntPtr.Zero) {CloseHandle(unmanagedResource);unmanagedResource = IntPtr.Zero;}disposed = true;}// 终结器作为安全网，防止忘记调用Dispose~ResourceHolder() {Dispose(false);}
}

使用using语句确保及时释放：

using (var resource = new ResourceHolder()) {// 使用资源
}  // 自动调用Dispose，即使发生异常

这个模式的精妙之处：

如果正确调用了Dispose，GC.SuppressFinalize会取消终结器，对象正常回收
如果忘记调用Dispose，终结器作为最后的防线，确保非托管资源被释放

七、实际应用中的GC优化

7.1 减少对象分配

最好的GC优化就是减少需要GC的对象。

案例：字符串拼接

// 极其糟糕的代码
string result = "";
for (int i = 0; i < 10000; i++) {result += i.ToString();  // 每次循环创建新字符串
}
// 产生10000个垃圾字符串对象// 正确做法
var sb = new StringBuilder(50000);  // 预分配合理的容量
for (int i = 0; i < 10000; i++) {sb.Append(i);
}
string result = sb.ToString();

案例：避免装箱

// 装箱示例
int value = 42;
object obj = value;  // 装箱：在堆上分配新对象
int value2 = (int)obj;  // 拆箱// 实际场景
var list = new ArrayList();
list.Add(1);  // 装箱
list.Add(2);  // 装箱
list.Add(3);  // 装箱// 正确做法：使用泛型
var list = new List<int>();
list.Add(1);  // 无装箱
list.Add(2);
list.Add(3);

案例：Span和Memory（.NET Core 2.1+）

// 传统方式：需要分配新数组
public byte[] GetSubArray(byte[] data, int start, int length) {byte[] result = new byte[length];Array.Copy(data, start, result, 0, length);return result;
}// 使用Span：零分配
public Span<byte> GetSubSpan(Span<byte> data, int start, int length) {return data.Slice(start, length);  // 只是创建一个视图，无内存分配
}

Span<T>是一个栈上分配的结构体，表示内存中的一段连续区域。它可以指向堆上的数组、栈上的数据，甚至非托管内存，而且不产生额外的堆分配。

7.2 对象池化

对于频繁创建和销毁的对象，可以使用对象池：

public class ObjectPool<T> where T : class, new() {private readonly ConcurrentBag<T> objects = new ConcurrentBag<T>();private readonly Func<T> factory;public ObjectPool(Func<T> factory = null) {this.factory = factory ?? (() => new T());}public T Rent() {return objects.TryTake(out T item) ? item : factory();}public void Return(T item) {objects.Add(item);}
}// 使用示例
public class MyService {private static ObjectPool<StringBuilder> sbPool =new ObjectPool<StringBuilder>(() => new StringBuilder(256));public string ProcessData(List<string> items) {var sb = sbPool.Rent();try {foreach (var item in items) {sb.Append(item);}return sb.ToString();}finally {sb.Clear();sbPool.Return(sb);}}
}

.NET提供了内置的ArrayPool<T>，强烈建议使用：

var pool = ArrayPool<byte>.Shared;
byte[] buffer = pool.Rent(1024);  // 租用至少1024大小的数组
try {// 使用buffer
}
finally {pool.Return(buffer, clearArray: true);  // 归还，可选清空内容
}

7.3 值类型 vs 引用类型

适当使用值类型可以减少堆分配：

// 引用类型：每次创建都在堆上分配
public class Point {public int X { get; set; }public int Y { get; set; }
}var points = new Point[1000];
for (int i = 0; i < 1000; i++) {points[i] = new Point { X = i, Y = i };  // 1000次堆分配
}// 值类型：在数组内部连续存储，只有一次堆分配（数组本身）
public struct Point {public int X { get; set; }public int Y { get; set; }
}var points = new Point[1000];  // 只有这一次堆分配
for (int i = 0; i < 1000; i++) {points[i] = new Point { X = i, Y = i };  // 直接写入数组，无额外分配
}

但值类型也有注意事项：

太大的值类型会导致大量的复制开销
值类型不支持继承
装箱会抵消所有优势

一般建议：小于16字节且逻辑上表示"值"的数据，考虑使用struct。

7.4 内存泄漏排查

即使有GC，C#程序也可能"泄漏"内存。本质上是对象仍然被引用，但逻辑上已经不再需要。

常见原因1：事件订阅

public class Publisher {public event EventHandler SomeEvent;
}public class Subscriber {public Subscriber(Publisher pub) {pub.SomeEvent += OnSomeEvent;// 忘记取消订阅！}private void OnSomeEvent(object sender, EventArgs e) { }
}// 问题：即使Subscriber不再使用，Publisher仍然持有它的引用
// Subscriber无法被GC回收

解决方案：

public class Subscriber : IDisposable {private Publisher publisher;public Subscriber(Publisher pub) {publisher = pub;publisher.SomeEvent += OnSomeEvent;}public void Dispose() {publisher.SomeEvent -= OnSomeEvent;}private void OnSomeEvent(object sender, EventArgs e) { }
}

或使用弱事件模式：

public class WeakEventSubscriber {public WeakEventSubscriber(Publisher pub) {WeakEventManager<Publisher, EventArgs>.AddHandler(pub, nameof(pub.SomeEvent), OnSomeEvent);}private void OnSomeEvent(object sender, EventArgs e) { }
}

常见原因2：静态集合

public class Cache {// 这个字典会永久持有所有添加的对象private static Dictionary<string, byte[]> cache =new Dictionary<string, byte[]>();public static void Add(string key, byte[] data) {cache[key] = data;  // 内存"泄漏"}
}

解决方案：使用MemoryCache或限制缓存大小：

public class Cache {private static readonly MemoryCache cache = new MemoryCache("MyCache");public static void Add(string key, byte[] data, TimeSpan expiration) {var policy = new CacheItemPolicy {AbsoluteExpiration = DateTimeOffset.Now.Add(expiration)};cache.Set(key, data, policy);  // 会自动过期}
}

或使用ConditionalWeakTable（键被回收时，条目自动删除）：

private static ConditionalWeakTable<object, byte[]> cache =new ConditionalWeakTable<object, byte[]>();

7.5 监控和诊断

运行时监控

public class GCMonitor {private Timer timer;public void Start() {timer = new Timer(_ => Report(), null,TimeSpan.Zero, TimeSpan.FromSeconds(10));}private void Report() {var info = GC.GetGCMemoryInfo();Console.WriteLine($"堆大小: {info.HeapSizeBytes / 1024 / 1024} MB");Console.WriteLine($"Gen0: {GC.CollectionCount(0)}, " +$"Gen1: {GC.CollectionCount(1)}, " +$"Gen2: {GC.CollectionCount(2)}");Console.WriteLine($"总内存: {GC.GetTotalMemory(false) / 1024 / 1024} MB");// .NET 5+Console.WriteLine($"碎片: {info.FragmentedBytes / 1024 / 1024} MB");Console.WriteLine($"暂停时间百分比: {info.PauseDurations.Sum().TotalMilliseconds}ms");}
}

使用诊断工具

Visual Studio Diagnostic Tools：实时内存图、对象追踪
dotMemory（JetBrains）：强大的内存分析器
PerfView：微软免费工具，可以看到详细的GC事件
dotnet-trace：.NET Core命令行工具

# 收集GC事件
dotnet-trace collect --process-id <pid> --providers Microsoft-Windows-DotNETRuntime:0x1:4# 查看内存使用
dotnet-counters monitor --process-id <pid> System.Runtime

分析内存快照

// 在Visual Studio中，可以在代码里触发内存快照
System.Diagnostics.Debugger.Break();  // 设置断点
// 在"诊断工具"窗口点击"拍摄快照"

八、高级话题

8.1 GC的配置选项

.NET Core/.NET 5+提供了丰富的配置选项

// runtimeconfig.json 或 环境变量
{"runtimeOptions": {"configProperties": {"System.GC.Server": true,                    // 服务器GC"System.GC.Concurrent": true,                // 并发GC"System.GC.RetainVM": true,                  // 保留虚拟内存"System.GC.HeapCount": 4,                    // 堆数量（服务器GC）"System.GC.HeapHardLimit": 1073741824,      // 1GB硬限制"System.GC.HeapHardLimitPercent": 75,       // 容器内存的75%"System.GC.HighMemoryPercent": 90,          // 高内存负载阈值"System.GC.ConserveMemory": 2               // 节约内存模式 0-9}}
}

在容器环境中，HeapHardLimitPercent特别有用：

# Dockerfile
ENV DOTNET_GCHeapHardLimitPercent=75# 如果容器限制为1GB，GC堆最多使用750MB

8.2 性能分析案例

案例：ASP.NET Core应用频繁Full GC

症状：

CPU使用率周期性飙升
响应时间出现毛刺
dotnet-counters显示Gen 2回收频繁

分析步骤：

使用dotnet-trace收集GC事件
在PerfView中打开trace文件
查看GC Stats Report

发现：

Gen 2堆大小持续增长
大量大对象分配

深入调查：

// 使用dotMemory或VS Profiler拍摄内存快照
// 发现大量byte[]占据Gen 2// 定位到问题代码
public class ImageService {public byte[] ProcessImage(Stream input) {var buffer = new byte[10 * 1024 * 1024];  // 问题所在！// 每个请求都分配10MB// ...}
}

修复：

public class ImageService {private static readonly ArrayPool<byte> pool = ArrayPool<byte>.Shared;public byte[] ProcessImage(Stream input) {byte[] buffer = pool.Rent(10 * 1024 * 1024);try {// 处理逻辑}finally {pool.Return(buffer);}}
}

结果：

Gen 2回收频率降低90%
P99延迟从500ms降到50ms

8.3 特殊场景

场景1：实时游戏

要求：60fps，每帧16ms，不能有明显的GC暂停。

策略：

public class GameManager {// 对象池化所有频繁创建的对象private ObjectPool<Bullet> bulletPool;private ObjectPool<Effect> effectPool;// 尽量使用值类型public struct Vector3 {public float X, Y, Z;}// 预分配集合private List<Enemy> enemies = new List<Enemy>(1000);public void Initialize() {// 启动时触发一次Full GCGC.Collect(2, GCCollectionMode.Forced, blocking: true);GC.WaitForPendingFinalizers();// 使用低延迟模式GCSettings.LatencyMode = GCLatencyMode.SustainedLowLatency;}public void Update() {// 游戏循环中避免任何分配}
}

场景2：低内存环境（嵌入式、移动设备）

// 设置保守的内存模式
GCSettings.LargeObjectHeapCompactionMode =GCLargeObjectHeapCompactionMode.CompactOnce;// 或使用配置
// "System.GC.ConserveMemory": 9  // 最大程度节约内存

场景3：批处理/数据处理

public class DataProcessor {public void ProcessLargeDataset() {// 暂时禁用并发GC，提高吞吐量var oldMode = GCSettings.LatencyMode;try {GCSettings.LatencyMode = GCLatencyMode.Batch;// 处理数据foreach (var batch in GetDataBatches()) {ProcessBatch(batch);// 每个批次后手动GC，避免内存累积GC.Collect(1, GCCollectionMode.Optimized);}}finally {GCSettings.LatencyMode = oldMode;}}
}