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

来源：这里教程网时间：2026-02-21 17:38:41 作者：

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

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

看似无 GC 的 async 方法，可能因

async/await

状态机生成闭包捕获局部变量（尤其是

Span<t></t>

、

ReadOnlyMemory<t></t>

），导致本该栈分配的对象被迫堆分配。典型案例如：

public async Task<string> ProcessAsync(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<byte>.Shared.Rent(4096)</byte>
并确保
Return()
调用（建议用
using
）避免在
async
方法内直接 new 大数组、大字典；把数据准备逻辑提前到同步阶段，或用
ValueTask
减少状态机开销

GC 停顿从来不是孤立问题——它暴露的是对象生命周期与并发模型的错配。真正有效的优化，往往发生在把一个