c# .NET 7 在并发和性能上的改进
.NET 7 中 Span/Memory 优化降低高并发 I/O 解析开销，ThreadPool 默认配置提升突发响应但需慎用预热，Server GC 减少 STW 时间，AOT 降低启动延迟和内存占用但牺牲动态特性。
Span 和 Memory 在高并发 I/O 中的实际收益
在 .NET 7 中，Span 和 Memory 的底层路径已深度优化，尤其在 System.IO.Pipelines 和 Kestrel 的缓冲区管理中体现明显。它们本身不是“新功能”，但 .NET 7 通过减少 ArrayPool 的锁争用、改进 ReadOnlySequence 的切片开销，让基于 Span 的解析逻辑（如 HTTP header 解析、JSON 反序列化）在高并发下更稳定。
实操建议：
- 避免在 hot path 上将
Span转为byte[]—— 这会触发堆分配和 GC 压力，.NET 7 并未改变这一根本约束 - 使用
Utf8Parser.TryParse替代int.Parse处理请求路径中的 ID 参数，它直接操作ReadOnlySpan，无字符串分配 - 注意
MemoryManager自定义实现仍需线程安全：.NET 7 不自动保证你的Memory子类在多线程GetMemory调用下的隔离性
ThreadPool 的默认配置变更与手动调优边界
.NET 7 将 ThreadPool 的默认最小工作线程数从 1 提升至 Environment.ProcessorCount（Windows/Linux 行为一致），同时引入了更激进的“饥饿检测”逻辑：当队列积压且空闲线程持续为 0 超过 10ms，会立即尝试注入新线程，而非等待传统指数退避。
这意味着：
- 短时突发请求（如 API 网关流量尖峰）响应延迟下降明显，但代价是线程创建/销毁频率上升
-
ThreadPool.SetMinThreads(100, 100)这类“防抖”式预热在 .NET 7 下反而可能干扰自适应策略，导致线程过剩和上下文切换开销增加 - 若应用长期运行于固定负载（如后台批处理服务），仍建议显式调用
ThreadPool.SetMaxThreads限制上限，防止突发异常任务耗尽系统资源
GC 在 Server GC 模式下的吞吐与暂停改进
.NET 7 的 Server GC 默认启用“背景 GC + 并发标记 + 并发清除”三阶段全并行，且将 Gen0 分配预算从 256KB 提升至 4MB（x64），显著降低 Gen0 GC 触发频次。更重要的是，它减少了 STW（Stop-The-World）时间中用于“根扫描”的占比 —— 尤其在拥有大量静态字段或大型 ConcurrentDictionary 的服务中效果突出。
关键注意事项：
- Gen2 GC 暂停时间未本质缩短，大对象堆（LOH）仍需靠
GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce主动干预 -
dotnet-counters中的gc-heap-size指标现在包含“待回收但尚未清扫的内存”估算值，比 .NET 6 更贴近真实压力 - 不要关闭
Server GC（即不设fa 
lse
lse原生 AOT 编译对并发性能的真实影响
.NET 7 正式支持 AOT 发布（dotnet publish -r win-x64 --aot），但它对“并发性能”的提升是间接且场景限定的：生成的本地代码消除了 JIT 编译开销，使首次请求延迟归零；同时因无运行时元数据和反射基础设施，内存占用下降约 15–25%，间接缓解 GC 压力。
但必须清楚：
- AOT 会禁用所有动态代码生成（
Reflection.Emit、Expression.Compile、大多数 ORM 的运行时模型构建）—— 若你用EF Core或AutoMapper，需提前验证兼容性 - 并发吞吐量（requests/sec）在稳定运行后与 JIT 版本基本持平，AOT 不改变锁竞争、线程调度或算法复杂度
-
HttpClient默认连接池行为在 AOT 下不变，但 DNS 解析若依赖System.Net.NameResolution的托管实现，可能因裁剪被移除，需显式保留
var pool = new SocketsHttpHandler
{
MaxConnectionsPerServer = 100,
PooledConnectionLifetime = TimeSpan.FromMinutes(5)
};
// .NET 7 中该配置在 AOT 下依然生效，但确保你没误删 System.Net.Http.dll 的依赖修剪规则
真正影响并发表现的，从来不是某一次 GC 暂停的毫秒级缩减，而是你是否让 async 真正穿透到最底层 I/O（比如用 Stream.ReadAsync(memory, token) 而非 Read(byte[], ...)），以及是否意识到 Task.Run 在高并发下只是把同步阻塞转移到线程池 —— 这点在 .NET 7 里反而更容易被忽略，因为线程池“看起来更聪明”了。
