答案取决于实现细节，但在这种形式中，它是不正确的。事实上，作者已经试图通过使用“轻微”一词来回避事实检查，以接受您从未观察到这样的性能差异的可能性。
如this board中所述，这样的语句背后的思想是，一个普通类有一个可重写方法表（也称为“vtable”），它被子类继承，子类可能会在末尾添加新的方法，并替换它们覆盖的方法的表项。因此，第一次解析只需要找到表索引，它可以被记住，因此后续调用只需要调用该索引处的实际接收器类的方法。
由于接口可能由不同的类实现，而这些类之间没有继承关系，因此实现方法可能位于这些类的不同表索引上。解决这个问题的一种方法是，从接口的表到实际类的表之间建立某种Map。假设这种双重调度导致了这样一种假设，即调用接口方法比调用普通方法要慢。
然而，像HotSpot JVM这样的JVM并不使用这样的双重调度。它们像任何其他虚拟方法调用一样，针对实际的接收器类来解析接口方法调用。只要接收器是同一个类层次结构的一部分，比如说，您在Appendable接口上调用一个方法，而接收器总是Writer类的子类。不需要额外的步骤。2对于大多数的接口方法调用来说，这是相当有效的。
在某些情况下，接口方法调用将在不相关类的不同实现处结束，比如，Appendable方法的调用有时在StringBuilder处结束，有时在Writer处结束，但是，我们有一个不可比的场景。这个特定的调用可能比普通方法调用稍慢，但是由于不可能用抽象类构造相同的场景，所以说它比这里使用抽象类慢没有任何意义。
对于与性能相关的代码部分（也称为热点），JVM将执行运行时优化，使这些技术差异变得无关紧要。即使是普通虚拟方法调用的微小开销通常也会被消除，因为后续优化严重依赖于积极内联目标方法代码的能力。以便能够使用调用方的上下文及其已知的周围条件来优化被调用方的代码。

• 与抽象类相比，接口速度慢，因为在解析对接口示例进行的函数调用时，JVM需要在虚拟表中查找以了解实现类的确切方法。此查找需要一些时间，而解析抽象类方法执行时不需要这些时间。
• 所以抽象类方法调用的执行比接口方法的执行快。
• 现代的JVM正在寻找在使用接口时减少这种速度损失的方法。