class="topic_img" alt=""/>
英文原文：Devirtualization in .NET Core
在 .NET 最初被设计出来时，方法在默认情况下必须是非虚方法。这有几个原因，其中一个是，非虚方法通常比虚方法快很多。除了虚函数表查询本身的成本之外，虚函数通常还无法内联。由于 .NET 的发展趋势是倾向于使用大量的小方法，所以非内联方法的函数调用开销最终会超过方法本身的开销。我们在文章“关于 C# 的抽象与 For-Each 性能”中介绍了这种内联的部分效果。
在过去的几年中，我们习惯的 C# 一直在变化。以前，大接口并不常见，但现在，可以完全匹配所有类的“影子接口”都非常常见了。这始于 WCF，它鼓励这种做法，虽然不是必须的。随着 DI 框架性能的提升，在项目中见到面向所有非 DTO 类的影子接口已经很平常了。
方法去虚有多种方式，本质上讲，就是在特定的情况下把它们视为非虚方法。Java HotSpot 就以具备这项特性而闻名。在 Java 中，所有方法在默认情况下都是虚方法，因此，在 Java 的历史中，解决这种性能问题的需求出现得早很多。
在今年三月份，.NET Core 悄悄地对“去虚（Devirtualization）”发起了挑战。简单去虚特性处理了三种基本的场景：
接口去虚也有一些基础的支持，但有限制。例如：
如果方法是 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 的情况，那么提升使用默认实现场景的执行速度是值得的。
相关文章
