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

为什么高并发下 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
,重点关注--providers "Microsoft-Windows-DotNETRuntime:4:4" GCSuspendEEStart/Stop和GCStart/End时间戳差值 - 检查
System.RuntimeEventSource 中的GCHeapStats,观察Gen0Size、Gen2PromotedBytesPerSec是否持续高于 10 MB/s - 用
PerfView打开 trace,筛选GC/AllocTick+GC/Start,看是否出现“小对象分配密集 → 短时间后 Gen0 GC → 紧接着 Gen2 GC”的链式反应
关键缓解手段:从代码和配置双路压制
GC 停顿不是调优出来的,是靠约束出来的。以下操作需组合使用:
- 启用服务器 GC(
):为每个逻辑 CPU 分配独立 GC 线程和堆,避免多线程争抢同一 GC 队列;注意它默认开启true Concurrent GC,但在 .NET 6+ 中已被Background GC取代,无需额外关断 - 禁用 LOH 自动压缩(
不推荐)→ 改用true GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce在低峰期手动触发(仅限 .NET Core 3.0+) - 避免隐式大对象:把
new byte[100_000]拆成池化ArrayPool;JSON 反序列化优先用.Shared.Rent(100_000) JsonSerializer.Deserialize而非(Utf8JsonReader) Deserialize,跳过 string → UTF8 字节数组转换(string) - 对高频创建的小对象(如 DTO、上下文容器),用
ObjectPool或MemoryPool,但注意池大小不能无限制增长,需配合.Shared MaxSize限流
最容易被忽略的陷阱:异步 + GC 的隐蔽耦合
看似无 GC 的 async 方法,可能因 async/await 状态机生成闭包捕获局部变量(尤其是 Span、ReadOnlyMemory),导致本该栈分配的对象被迫堆分配。典型案例如:
public async TaskProcessAsync(string input) { var buffer = new byte[4096]; // → LOH! await stream.ReadAsync(buffer, ...); // buffer 被状态机捕获 return Encoding.UTF8.GetString(buffer); // 再次触发 string 分配 }
正确做法是:
- 用
stackalloc byte[4096](仅限unsafe上下文且 size 固定) - 或改用
MemoryPool并确保.Shared.Rent(4096) Return()调用(建议用using) - 避免在
async方法内直接 new 大数组、大字典;把数据准备逻辑提前到同步阶段,或用ValueTask减少状态机开销
GC 停顿从来不是孤立问题——它暴露的是对象生命周期与并发模型的错配。真正有效的优化,往往发生在把一个 new List 替换成 ArrayPool 的那一行,而不是 GC 参数调优的第十个配置项。










