c# 高并发应用中的 GC 停顿问题分析和解决-C#.Net教程-PHP中文网

高并发下GC停顿变长主因是Gen 0晋升速率过高引发频繁Gen 1/2回收，叠加LOH碎片化；需用dotnet-trace抓GCSuspendEE与GCStart时间差、观察Gen2PromotedBytesPerSec是否超10MB/s，并组合启用服务器GC、LOH压缩、对象池及避免async隐式堆分配来缓解。

c# 高并发应用中的 gc 停顿问题分析和解决

为什么高并发下 GC 停顿会突然变长？

不是因为对象总量大，而是因为 Gen 0 晋升速率过高，导致频繁触发 Gen 1 和 Gen 2 回收。在高吞吐场景（如 Web API、实时消息处理）中，短生命周期对象暴增（比如 JSON 反序列化产生的临时字符串、Dictionary 的内部数组扩容），但若线程局部分配缓冲区（TLAB）耗尽或存在大对象（≥ 85 KB），就会绕过 TLAB 直接进入 LOH（Large Object Heap），而 LOH 只在 Gen 2 GC 时才回收——且不压缩，容易碎片化，进一步诱发更重的 GC。

如何确认是 GC 导致的停顿？

别只看 GC.Collect() 调用日志，要抓真实指标：

用 dotnet-trace 录制运行时事件：
```
dotnet-trace collect --process-id <pid> --providers "Microsoft-Windows-DotNETRuntime:4:4"</pid>
```
，重点关注 GCSuspendEEStart/Stop 和 GCStart/End 时间戳差值
检查 System.Runtime EventSource 中的 GCHeapStats，观察 Gen0Size、Gen2PromotedBytesPerSec 是否持续高于 10 MB/s
用 PerfView 打开 trace，筛选 GC/AllocTick + GC/Start，看是否出现“小对象分配密集 → 短时间后 Gen0 GC → 紧接着 Gen2 GC”的链式反应

关键缓解手段：从代码和配置双路压制

GC 停顿不是调优出来的，是靠约束出来的。以下操作需组合使用：

启用服务器 GC（true）：为每个逻辑 CPU 分配独立 GC 线程和堆，避免多线程争抢同一 GC 队列；注意它默认开启 Concurrent GC，但在 .NET 6+ 中已被 Background GC 取代，无需额外关断
禁用 LOH 自动压缩（true 不推荐）→ 改用 GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce 在低峰期手动触发（仅限 .NET Core 3.0+）
避免隐式大对象：把 new byte[100_000] 拆成池化 ArrayPool.Shared.Rent(100_000)；JSON 反序列化优先用 JsonSerializer.Deserialize(Utf8JsonReader) 而非 Deserialize(string)，跳过 string → UTF8 字节数组转换
对高频创建的小对象（如 DTO、上下文容器），用 ObjectPool 或 MemoryPool.Shared，但注意池大小不能无限制增长，需配合 MaxSize 限流

最容易被忽略的陷阱：异步 + GC 的隐蔽耦合

看似无 GC 的 async 方法，可能因 async/await 状态机生成闭包捕获局部变量（尤其是 Span、ReadOnlyMemory），导致本该栈分配的对象被迫堆分配。典型案例如：

deepstream-dev

使用 Python pyservicemaker API 进行 NVIDIA DeepStream SDK 开发。在构建视频分析流水线、基于 GStreamer

下载

public async Task<string> ProcessAsync(string input)
{
    var buffer = new byte[4096]; // → LOH！
    await stream.ReadAsync(buffer, ...); // buffer 被状态机捕获
    return Encoding.UTF8.GetString(buffer); // 再次触发 string 分配
}</string>

正确做法是：