多数情况下没用，甚至有害；.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<t></t>或无锁结构（如Channel<t></t>）替代手动加锁的List<t></t>+lock - 避免在热路径中分配短生命周期对象 → 改用
Span<t></t>、stackalloc或对象池（ArrayPool<t>.Shared</t>） - 写共享变量时注意对齐：用
[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 序列化时的字符串拼接上。
