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