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 延迟的相关性：
用dotnet-trace collect --providers Microsoft-Windows-DotNETRuntime:4:4抓取运行时事件，过滤
GCSuspendEEStart/
GCSuspendEEEnd计算实际暂停时间 禁用
LOH压缩（
System.GC.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce）可减少 Gen2 停顿，但仅适用于 .NET 5+ 避免分配 >85KB 对象：用
ArrayPool<byte>.Shared.Rent()</byte>替代
new byte[100_000]，防止意外落入 LOH 对高频路径做对象复用：如用
ValueStringBuilder替代
string.Format，用
Span<char></char>解析而非
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：
<servergarbagecollection>true</servergarbagecollection>+
<retainvm>false</retainvm>对延迟一致性要求极高的服务（如高频交易网关），可测试
Workstation GC+
Concurrent组合：它暂停更短、更频繁，P99 延迟反而更平稳
GCSettings.LatencyMode = GCLatencyMode.LowLatency仅在极短窗口（秒级）有效，且会禁用 Gen2 回收，切勿长期启用 STW 的影响不在“停多久”，而在“停得是否可预测”。真正难处理的，是那些因内存布局碎片、LOH 堆积、或第三方库隐式分配引发的偶发长暂停——它们不会出现在平均值里，却会精准打穿你的 SLA。
