根据这篇文章，在抽象类与接口上，抽象类比接口略快。为什么会这样，您能解释一下在JVM中使用接口与抽象类的机制吗？
- Java 中抽象类和接口的第四个区别 是抽象类比接口稍快，因为 接口涉及在调用任何重写方法之前进行搜索 爪哇岛。在大多数情况下，这不是显着差异，但如果 您正在编写一个时间紧迫的应用程序，那么您可能不想 不遗余力。
答案取决于实现细节，但在这种形式中，它是不正确的。事实上，作者已经试图通过使用"稍微"这个词来回避事实核查，以开放你从未观察到这种性能差异的可能性。
正如本板中所阐述的，这种陈述背后的想法是，一个普通类有一个可重写方法表(也称为"vtable"(，该表由子类继承，子类可能会在末尾添加新方法并替换它们覆盖的方法的表条目。因此，第一个解析只需要找到可以记住的表索引，因此后续调用只需要在该索引处调用实际接收器类的方法。
由于接口可能由不具有继承关系的不同类实现，因此实现方法可能位于这些类的不同表索引处。解决此问题的一种方法是从接口的表到实际类的表进行某种映射。假设这种双重调度会导致调用接口方法比普通方法慢的假设。
但是，像HotSpot JVM这样的JVM不使用这种双重调度。它们像任何其他虚拟方法调用一样针对实际的接收器类解析接口方法调用。只要接收器是同一类层次结构的一部分，例如，您在Appendable接口上调用方法，并且接收器始终是Writer类的子类，就不需要额外的步骤。对于大多数接口方法调用，这相当有效。
在某些情况下，接口方法调用最终会出现在不相关类的不同实现中，例如，当对Appendable方法的调用有时以StringBuilder结束，有时以Writer结束，但是，我们有一个无与伦比的场景。这种特定的调用可能比普通方法调用稍慢，但由于不可能用抽象类构造相同的场景，因此说它比在这里使用抽象类慢是没有任何意义的。
对于与性能相关的代码部分(也称为热点(，JVM将执行运行时优化，这使得这种技术差异无论如何都无关紧要。即使是普通虚拟方法调用的微小开销通常也会被消除，因为后续优化在很大程度上依赖于主动内联目标方法代码的能力，以便能够使用调用方的上下文及其已知的周围条件来优化被调用方的代码。
- 与抽象类相比，接口很慢，因为在解析对接口实例进行的函数调用，JVM需要 在虚拟表中查找以了解确切的实现方法 .class。此查找需要解决不需要的时间 抽象类方法执行。
- 所以抽象类方法调用 执行速度比接口方法执行快。
- 现代 JVM 的 正在探索在使用时减少这种速度损失的方法 接口。