Span 和 Memory 在高并发 I/O 中的实际收益
在 .NET 7 中，
Span<t></t>和
Memory<t></t>的底层路径已深度优化，尤其在
System.IO.Pipelines和
Kestrel的缓冲区管理中体现明显。它们本身不是“新功能”，但 .NET 7 通过减少
ArrayPool<t>.Shared.Rent()</t>的锁争用、改进
ReadOnlySequence<t></t>的切片开销，让基于
Span的解析逻辑（如 HTTP header 解析、JSON 反序列化）在高并发下更稳定。
实操建议：
避免在 hot path 上将Span<byte></byte>转为
byte[]—— 这会触发堆分配和 GC 压力，.NET 7 并未改变这一根本约束 使用
Utf8Parser.TryParse替代
int.Parse处理请求路径中的 ID 参数，它直接操作
ReadOnlySpan<byte></byte>，无字符串分配 注意
MemoryManager<t></t>自定义实现仍需线程安全：.NET 7 不自动保证你的
Memory<t></t>子类在多线程
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（即不设
<servergarbagecollection>false</servergarbagecollection>）—— .NET 7 的 Client GC 已被标记为 legacy，且无对应优化
原生 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的托管实现，可能因裁剪被移除，需显式保留
<trimmerrootassembly include="System.Net.NameResolution"></trimmerrootassembly>
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 里反而更容易被忽略，因为线程池“看起来更聪明”了。
