c# AggressiveInlining 和高并发下的性能优化_网络技术

发布时间 - 2026-01-05 00:00:00 点击率：次

多数情况下没用，甚至有害；.NET JIT 对 AggressiveInlining 的内联决策受函数大小、控制流复杂度、异常处理等硬性限制，高并发下更关键的是减少锁争用、避免内存分配和缓存伪共享。

多数情况下没用，甚至有害。.NET JIT 对 AggressiveInlining 的实际内联决策仍受函数大小、控制流复杂度、是否含异常处理等硬性限制；高并发下更关键的是减少锁争用、避免内存分配和缓存行伪共享，而非强行把一个 20 行带 try/catch 的方法塞进调用点。

仅适用于极简、无分支、无对象分配、无 P/Invoke、无虚调用的热路径辅助函数。典型如：

一旦函数体含 new、lock、await、yield return 或任何非 trivial 的条件跳转，JIT 会直接忽略该标记。

真正影响吞吐量的是内存访问模式与同步原语选择：

用 ConcurrentQueue 或无锁结构（如 Channel）替代手动加锁的 List + lock
避免在热路径中分配短生命周期对象 → 改用 Span、stackalloc 或对象池（ArrayPool.Shared）
写共享变量时注意对齐：用 [StructLayout(LayoutKind.Explicit)] + [FieldOffset] 隔离不同线程频繁写的字段，防止伪共享
计数器类场景优先用 Unsafe.Add(ref location, value) + Volatile.Read，而非 Interlocked.Increment（后者隐含 full fence）

public struct Counter
{
    [FieldOffset(0)] private long _value;
    [FieldOffset(16)] private long _padding; // 防止与相邻字段共享 cache line
}

不能只看代码有没有加标记，必须实测生成的汇编：

启用 Tiered Compilation 关闭：DOTNET_TieredCompilation=0，避免预热阶段误导
用 dotnet-dump collect + dumpheap -stat 观察热路径对象分配量是否下降
用 dotnet-trace collect --providers Microsoft-Windows-DotNETRuntime:4:4 检查 JitInliningSucceeded 事件
最可靠方式：用 dotnet tool install -g dotnet-pdbs + dotnet-pdbs --asm 查看 JIT 输出的 x64 汇编，确认目标方法是否被展开

很多团队花时间给错误的方法加 AggressiveInlining，却没发现瓶颈其实在 HttpClient 的连接复用率或 JSON 序列化时的字符串拼接上。