Server GC与Workstation GC的核心区别在于内存管理策略：前者为每个CPU核心分配独立堆和专用线程，并行回收；后者仅用单堆，GC时暂停所有托管线程，支持并发标记但延迟更低。
Server GC 和 Workstation GC 的核心区别在哪
根本差异在于内存管理策略：Server GC 为每个 CPU 核心分配独立的 GC 堆和专用回收线程，所有 GC 操作并行执行；Workstation GC（默认）只用一个堆，GC 时会暂停所有托管线程，且支持并发标记（Concurrent GC），但仅限于后台 GC 模式（.NET Framework）或在 .NET 5+ 中被统一为 Workstation 模式下的 Concurrent 选项。
这意味着：高并发场景下，Server GC 更擅长吞吐量优先的长连接服务（如 ASP.NET Core Web API），而 Workstation GC 更适合交互式应用（如 WinForms），其低延迟特性对短时响应敏感的场景更友好——但高并发时反而容易因频繁触发 GC 导致 STW（Stop-The-World）时间累积、请求毛刺增多。
ASP.NET Core 默认启用 Server GC 吗
从 .NET 5 开始，dotnet new webapi 生成的项目默认启用 Server GC，前提是运行环境满足条件：Windows/Linux 上检测到多核 CPU 且未显式禁用。但要注意，它不是靠运行时自动“猜测”，而是依赖 runtimeconfig.json 中的配置项生效。
-
Server GC必须通过gcServer设置为true才启用，否则即使多核也回退到 Workstation - 发布时若用
dotnet publish -r win-x64，该设置仍需手动确认；容器环境（如 Alpine Linux）可能因 cgroup 限制导致 .NET 误判 CPU 数量，进而不启用 Server GC - 可通过代码验证：
Console.WriteLine(GCSettings.IsServerGC);
—— 生产部署前务必检查输出是否为True
高并发下 Server GC 的典型问题表现
并非开了 Server GC 就万事大吉。常见反模式会导致 GC 反而成为瓶颈：
- 大量短期对象持续分配（如每请求创建大数组、JSON 序列化未复用
JsonSerializerOptions），引发 Gen 0 频繁回收，虽并行但线程竞争加剧 - 对象存活时间变长（如缓存未设限、
HttpClient实例全局单例但未正确复用），导致 Gen 2 压力上升，Server GC 的 Gen 2 回收仍是 STW，且耗时更长 - 异步 I/O 后续同步阻塞（如
Task.Result或.Wait()），使线程池饥饿，GC 线程争抢 CPU，表现为 GC 时间飙升、% Time in GC性能计数器持续 >10% - 未关闭大对象堆（LOH）优化：.NET 5+ 默认启用 LOH 压缩，但若仍使用旧版或显式关闭（
<gcallowverylargeobjects>false</gcallowverylargeobjects>），>85KB 对象易碎片化，Server GC 的 LOH 回收不压缩，加剧内存浪费
怎么验证和调优 GC 行为
不能只看 IsServerGC 返回值，得结合运行时指标和内存行为判断是否真正受益：
- 启用 GC 日志：
DOTNET_GCLog=1+DOTNET_GCLogEvents=ALL，观察日志中Pause time分布和Generation 2 collection频次 - 用
dotnet-counters monitor -p <pid> --counters System.Runtime</pid>实时查看：Gen 0/1/2 collections、% Time in GC、LOH size - 压测时对比关键指标：相同 QPS 下，Server GC 应显著降低平均 GC 暂停时间（尤其 Gen 0），但若
Alloc Rate / sec过高，反而可能因并行 GC 线程开销拉高 CPU 使用率 - 强制 GC 调试用法（仅开发）：
GC.Collect(2, GCCollectionMode.Forced, blocking: true);
避免在生产环境调用，它会破坏 Server GC 的节奏
最常被忽略的一点：GC 模式只是内存策略的起点，真正影响高并发稳定性的，是对象生命周期设计——比如用 ArrayPool<byte>.Shared.Rent()</byte> 替代 new byte[4096]，比切换 GC 模式带来的收益大一个数量级。
