17370845950

.NET 6+ 的 GC Stop-the-World 并未完全消除暂停，关键阶段（如 Gen2/LOH 回收）仍会冻结所有托管线程，实测暂停达 10–50ms；高并发加剧其破坏性，async/await 无法绕过，需通过 tracing 定位、对象复用、禁用 LOH 压缩、合理选配 GC 模式等缓解。

GC 的 Stop-the-World 在 .NET 6+ 中是否真的“停”了整个应用？

不是完全停，但关键阶段仍会暂停所有托管线程——尤其是 Gen2 或 LOH（大对象堆）回收时。.NET 6 引入的 Concurrent GC（默认启用）把大部分标记工作移到后台线程，但仍有短暂停顿：比如 STW 阶段需冻结线程以拍摄堆快照、重定位对象指针、更新句柄表。实测中，一次 Gen2 回收可能带来 10–50ms 的暂停，对延迟敏感服务（如金融报价、实时游戏同步）已足够触发超时。

高并发下 STW 暂停被放大的真实原因

高并发本身不直接导致 GC 更频繁，但会加剧 STW 的破坏性：

• ThreadPool 线程在 STW 期间无法响应新请求，积压的 Task 延迟升高，引发级联超时
• 大量短生命周期对象（如 JSON 反序列化产生的 string、Dictionary）推高 Gen0 分配率，间接增加 Gen2 升级概率
• 使用 async/await 并不能绕过 STW：await 之后的 continuation 仍需在 GC 后恢复执行，若此时刚结束 STW，调度延迟叠加
• 某些日志库（如 Serilog 启用 Enrichers）或监控 SDK（如 OpenTelemetry）在每次调用中分配临时对象，成为隐式 GC 压力源

如何定位和缓解 STW 对吞吐的影响？

别只看 GC 次数，重点观察暂停时长分布与请求 P99 延迟的相关性：

• 用 dot

  

  net-trace collect --providers Microsoft-Windows-DotNETRuntime:4:4 抓取运行时事件，过滤 GCSuspendEEStart / GCSuspendEEEnd 计算实际暂停时间
• 禁用 LOH 压缩（System.GC.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce）可减少 Gen2 停顿，但仅适用于 .NET 5+
• 避免分配 >85KB 对象：用 ArrayPool.Shared.Rent() 替代 new byte[100_000]，防止意外落入 LOH
• 对高频路径做对象复用：如用 ValueStringBuilder 替代 string.Format，用 Span 解析而非 Split()

var sb = new ValueStringBuilder(stackalloc char[256]);
sb.Append("user_id:");
sb.Append(userId);
var key = sb.ToString(); // 不触发堆分配
sb.Dispose();

Server GC 和 Workstation GC 的选择陷阱

很多人以为“Server GC = 高并发首选”，但忽略了一个关键前提：它默认启用 Concurrent GC，却也默认开启 RetainVM（保留已释放内存），导致 RSS 持续增长。在容器环境（如 Kubernetes）中，这可能触发 OOMKilled。更糟的是，当内存压力突增时，Server GC 会尝试一次完*部回收，反而拉长单次 STW。

• 若部署在固定内存的容器中，建议显式关闭 RetainVM：true + false
• 对延迟一致性要求极高的服务（如高频交易网关），可测试 Workstation GC + Concurrent 组合：它暂停更短、更频繁，P99 延迟反而更平稳
• GCSettings.LatencyMode = GCLatencyMode.LowLatency 仅在极短窗口（秒级）有效，且会禁用 Gen2 回收，切勿长期启用

STW 的影响不在“停多久”，而在“停得是否可预测”。真正难处理的，是那些因内存布局碎片、LOH 堆积、或第三方库隐式分配引发的偶发长暂停——它们不会出现在平均值里，却会精准打穿你的 SLA。