贝利信息

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

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

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

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

进一步诱发更重的 GC。

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

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

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

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

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

看似无 GC 的 async 方法,可能因 async/await 状态机生成闭包捕获局部变量(尤其是 SpanReadOnlyMemory),导致本该栈分配的对象被迫堆分配。典型案例如:

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

正确做法是:

GC 停顿从来不是孤立问题——它暴露的是对象生命周期与并发模型的错配。真正有效的优化,往往发生在把一个 new List() 替换成 ArrayPool.Shared.Rent(128) 的那一行,而不是 GC 参数调优的第十个配置项。