虚方法调用在高并发下真会拖慢性能？
在 C# 中，
virtual方法调用本身不会因为“高并发”而突然变慢——瓶颈不在并发度，而在 JIT 编译器是否能对具体调用点做 单态内联（monomorphic inline）。如果运行时类型稳定（比如总是
DerivedA），JIT 可能将虚调用优化成直接调用甚至内联；但如果类型频繁切换（如
DerivedA、
DerivedB、
DerivedC交替出现），JIT 会退回到查虚函数表（vtable）+ 间接跳转，带来几纳秒到十几纳秒的额外开销。这点在每秒百万级调用的热点路径上会累积成可观延迟。
如何判断你的虚调用是否被内联？
最可靠的方式是查看 JIT 生成的汇编代码。启用以下配置后运行程序并捕获日志：
设置环境变量：CORECLR_ENABLE_INLINING=1和
CORECLR_LOGGING=1或使用
dotnet trace+
PerfView捕获
Jit/JitInliningSucceeded事件 关键线索：日志中出现类似
Inline candidate not inlinable: 'MyType.VirtualMethod' (IL size: 24) because 'virtual method'表示未内联
注意：.NET 6+ 对密封类（
sealed）中的
virtual方法、以及被
override但无进一步派生的类，内联概率显著提高；但只要基类没标
sealed，且存在多个活跃派生类型，JIT 通常保守处理。
直接调用（非虚）和虚调用的实际差异示例
public class Base
{
public virtual int GetId() => 42;
public int GetIdDirect() => 42;
}
<p>public class Derived : Base
{
public override int GetId() => 100;
}</p><p>// 热点循环（模拟高并发下的密集调用）
for (int i = 0; i < 1000_000; i++)
{
// 场景1：多态引用，实际类型固定为 Derived
int x = obj.GetId(); // 虚调用 —— 若 JIT 判定为 monomorphic，可能内联为 100；否则走 vtable</p><pre class='brush:php;toolbar:false;'>// 场景2：直接调用
int y = obj.GetIdDirect(); // 总是直接 call，无虚分发开销}
在真实压测中（如用
BenchmarkDotNet），若
obj是
Base类型但始终指向
Derived实例，两者差距常小于 5%；但若
obj在循环中混杂不同派生类型（
DerivedA/
DerivedB），虚调用可能慢 1.5–3×。这不是并发导致的，而是类型多样性触发了去优化路径。
什么情况下该认真考虑替换虚方法？
当同时满足以下条件时，虚方法开销才值得干预：
该方法位于每秒调用超 100 万次的 CPU 密集路径（如序列化器核心、高频事件处理器） 实际运行时存在 ≥3 种活跃派生类型，且无法通过重构收束（例如插件系统必须开放继承） 已用dotnet-trace确认该虚调用占用了 >2% 的采样火焰图宽度 你愿意接受牺牲部分可扩展性换取确定性性能（比如改用
Func<t></t>注入、接口+结构体实现、或源生生成器预分派）
多数业务代码里，虚方法调用的开销远小于一次数据库 round-trip 或 JSON 序列化——过早为它加锁、缓存或强行去虚化，反而让逻辑更难维护。真正卡住高并发系统的，几乎从来不是虚函数表查表本身。
