.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