分代gc是.net运行时默认启用的强制机制，按对象生命周期分gen 0/1/2回收，gen 2停顿长易致响应延迟；需监控% time in gc>5%、gen 2 p95>15ms等指标及时干预。
分代 GC 是什么，为什么 .net 并发应用不能忽略它
分代垃圾回收不是“可选优化”，而是 .NET 运行时默认启用的强制行为——GC.Collect() 默认只触发 Gen 0 回收，而 Gen 1 和 Gen 2 的回收成本高、停顿长，直接影响并发吞吐和响应延迟。你写的异步服务、高频率 API 或后台 Worker，只要对象生命周期不匹配代龄划分（比如短命对象意外滞留到 Gen 2），就会在某个请求里突然卡住几百毫秒。
Gen 0 频繁触发但影响小，Gen 2 却可能拖垮整个服务
Gen 0 回收快（通常 Gen 0 回收，就会被提升到 Gen 1，再活过一次就进 Gen 2。而 Gen 2 回收要遍历整个托管堆（包括大对象堆 LOH），且是**阻塞式全暂停（STW）**，哪怕只是 50MB 的 Gen 2 堆，也可能导致 20–100ms 的停顿——这对 HttpClient 池复用、SignalR 心跳或 gRPC streaming 来说就是超时源头。
- 避免让短期对象升代：比如用
StringBuilder拼接日志时反复.Clear()而非新建实例，防止内部缓冲区被提升 - 大数组（≥85,000 字节）直接进 LOH，不参与 Gen 0/1 回收，且 LOH 只在
Gen 2回收时整理（默认不压缩），容易碎片化 → 后续分配失败触发额外Gen 2 -
ArrayPool<byte>.Shared.Rent(1024)</byte>这类复用能显著减少 Gen 0 压力，但若租期过长（比如跨 await 边界未及时Return），池内数组可能被提升到更高代
Concurrent GC 和 Server GC 的关键区别在哪
.NET 默认启用的是 Server GC（多线程并行回收），但它**不是完全并发的**：Gen 0/1 回收期间仍需 STW，只有 Gen 2 的标记阶段可与用户线程并发运行（即 Background GC）。是否启用 Background GC 取决于运行时版本和配置：
<configuration> <runtime> <gcServer enabled="true" /> <!-- .NET 5+ 默认开启 background GC；.NET Core 3.1 需显式设置 --> <gcConcurrent enabled="true" /> </runtime> </configuration>- 没开
gcConcurrent：Gen 2 回收全程 STW，停顿时间 = 标记 + 清扫 + 压缩，极易在高负载下雪崩 - 开了但用了大量
WeakReference或Finalizer：终结器队列处理仍发生在 STW 阶段，会延长实际停顿 - Server GC 在容器环境（如 Docker）中若未正确设置 CPU 限制，可能因检测到“单核”而退化为 Workstation GC，失去并行能力
怎么验证你的应用正被 GC 拖慢
别猜，用真实指标说话。Windows 上优先看 PerfView 的 GCStats 事件，重点关注三项：
-
Gen 2 Heap Size是否持续 >200MB？说明有内存泄漏或对象驻留过久 -
Pause Time (ms)中 Gen 2 的 P95 >15ms？基本确认是 GC 瓶颈 -
Allocation MB/Sec突然飙升 + Gen 0 数量激增？典型是字符串拼接、json 序列化未复用JsonSerializerOptions
Linux 上可用 dotnet-counters monitor -p <pid> --counters System.Runtime</pid> 实时观察 % Time in GC，超过 5% 就该介入。注意：GC Total Pause Time 是累计值，要结合 GC Count 算均值，否则单次长停顿会被稀释。
最隐蔽的问题往往出在“以为安全”的地方：比如 Entity Framework 的 AsNoTracking() 能减少 Gen 0 分配，但如果查询结果里包含未清理的导航集合（IEnumerable<t></t> 被多次枚举），反而会生成更多中间对象升代。GC 不会替你修复逻辑缺陷，只会把问题放大成延迟尖刺。