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

AggressiveInlining 在高并发场景下真的有用吗

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

哪些函数适合加 [MethodImpl(MethodImplOptions.AggressiveInlining)]

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

• Math.Min/Math.Max 封装（但 .NET 6+ 已内置内联）
• 位运算包装：如 IsEven(int x) => (x & 1) == 0
• 简单状态检查：如 IsDisposed => _disposed（字段直读）
• 不带副作用的 getter，且 JIT 未自动内联（可通过 dotnet trace 验证）

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

高并发下比 AggressiveInlining 更有效的优化点

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

• 用 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
}

如何验证 AggressiveInlining 是否生效

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

• 启用 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 序列化时的字符串拼接上。