.NET Core 中的去虚

在.NET 最初被设计出来时，方法在默认情况下必须是非虚方法。这有几个原因，其中一个是，非虚方法通常比虚方法快很多。除了虚函数表查询本身的成本之外，虚函数通常还无法内联。由于.NET 的发展趋势是倾向于使用大量的小方法，所以非内联方法的函数调用开销最终会超过方法本身的开销。我们在文章“关于 C#的抽象与 For-Each 性能”中介绍了这种内联的部分效果。

在过去的几年中，我们习惯的 C#一直在变化。以前，大接口并不常见，但现在，可以完全匹配所有类的“影子接口”都非常常见了。这始于 WCF，它鼓励这种做法，虽然不是必须的。随着 DI 框架性能的提升，在项目中见到面向所有非 DTO 类的影子接口已经很平常了。

方法去虚有多种方式，本质上讲，就是在特定的情况下把它们视为非虚方法。Java HotSpot 就以具备这项特性而闻名。在 Java 中，所有方法在默认情况下都是虚方法，因此，在 Java 的历史中，解决这种性能问题的需求出现得早很多。

在今年三月份，.NET Core 悄悄地对“去虚（Devirtualization）”发起了挑战。简单去虚特性处理了三种基本的场景：

• 在 sealed 类上调用虚方法；
• 在 sealed 方法上调用虚方法；
• 在明确知道类型的情况下调用虚方法（例如，紧挨着构造函数）。

接口去虚也有一些基础的支持，但有限制。例如：

如果方法是 final 的，而类不明确或者不是 final 的，则不允许接口去虚，因为派生类在实现接口时还可以重写 final 方法。

需要注意的是，仅仅将类标记为“sealed”是不足以从去虚接口受益的。如果你正在使用 DI 框架隐藏运行时使用了哪个具体类，那么 JIT 编译器可能无法确定使用了什么类型。

这在 Java 中之所以不是问题，是因为 Java 去虚技术的工作原理完全不同。它是根据运行时指标试探性地去虚接口调用，对最常调用的方法重新即时编译。其中还包含了专门的防卫语句，以防具体的类型修改和去虚需要解除。

展望

.NET Core 2.0 提供了上述特性，但还有许多工作要做。下面是去虚路线图上的部分重点工作。

众所周知，在涉及接口调用时，结构很糟糕，因为它们不仅是虚的，而且还需要对值进行装箱。因此，有几项工作是为了尽可能地减少虚调用和装箱。其中一个重要的部分是一类结构，这是一个高级JIT 概念，超出了本报道的范围。

JIT 本身的类型跟踪改进。显然，在许多情况下，JIT 在一个地方知道具体的类型，但无法将信息传递下去，因此，JIT 不得不采用更通用的机器代码。

试探性去虚也在考虑范围。根据概述，该特性不会和 Java 里的一样。更准确地说，它会根据 JIT 过程中已知的覆写清单做决定。（据推测，这会用在接口只有单个类实现的情况下，这在上文提到的 DI 场景下经常发生。）

其中有一种特殊情况，就是 EqualityComparer.Default防卫去虚。由于在绝大多数情况下，IEqualityComparer 调用都会指向默认实现（视情况不同，要么是IEquatable，要么是Object.Equals），所以他们觉得，如果不减慢使用非默认IEqualityComparer 的情况，那么提升使用默认实现场景的执行速度是值得的。

查看英文原文： Devirtualization in .NET Core