.NET Core中的去虚

微软 语言 .NET

摘要

在使用抽象类和接口时，去虚可以提升性能。这项技术正慢慢进入.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的情况，那么提升使用默认实现场景的执行速度是值得的。

查看英文原文：去虚 in .NET Core