在我们开始像撒纸屑一样抛出基准测试之前，让我们回顾一下这两者的区别：

  • 抽象类：面向对象编程的重量级选手。可以有状态、构造函数，以及抽象和具体方法。
  • 接口：轻量级选手。传统上是无状态的，但自从Java 8以来，它们通过默认和静态方法变得更加强大。

这里有一个快速比较来帮助我们思考：


// 抽象类
abstract class AbstractVehicle {
    protected int wheels;
    public abstract void drive();
    public void honk() {
        System.out.println("Beep beep!");
    }
}

// 接口
interface Vehicle {
    void drive();
    default void honk() {
        System.out.println("Beep beep!");
    }
}

性能谜题

现在，你可能会想，“当然，它们不同，但在性能上真的有关系吗？”好吧，我好奇的程序员，这正是我们要找出的。让我们启动JMH，看看情况如何。

进入JMH：基准测试的低语者

JMH（Java微基准测试工具）是我们这次性能调查的可靠助手。它就像是你代码执行时间的显微镜，帮助我们避免天真的基准测试陷阱。

要开始使用JMH，请在你的pom.xml中添加以下内容：


<dependency>
    <groupId>org.openjdk.jmh</groupId>
    <artifactId>jmh-core</artifactId>
    <version>1.35</version>
</dependency>
<dependency>
    <groupId>org.openjdk.jmh</groupId>
    <artifactId>jmh-generator-annprocess</artifactId>
    <version>1.35</version>
</dependency>

设置基准测试

让我们创建一个简单的基准测试来比较抽象类和接口的方法调用：


import org.openjdk.jmh.annotations.*;
import java.util.concurrent.TimeUnit;

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@State(Scope.Benchmark)
@Fork(value = 1, warmups = 2)
@Warmup(iterations = 5, time = 1)
@Measurement(iterations = 5, time = 1)
public class AbstractVsInterfaceBenchmark {

    private AbstractVehicle abstractCar;
    private Vehicle interfaceCar;

    @Setup
    public void setup() {
        abstractCar = new AbstractVehicle() {
            @Override
            public void drive() {
                // Vrooom
            }
        };
        interfaceCar = () -> {
            // Vrooom
        };
    }

    @Benchmark
    public void abstractClassMethod() {
        abstractCar.drive();
    }

    @Benchmark
    public void interfaceMethod() {
        interfaceCar.drive();
    }
}

运行基准测试

现在，让我们运行这个基准测试，看看结果如何。记住，我们测量的是以纳秒为单位的平均执行时间。


# 运行基准测试
mvn clean install
java -jar target/benchmarks.jar

结果出来了！

在运行基准测试后（结果可能因你的具体硬件和JVM而异），你可能会看到这样的结果：


Benchmark                                   Mode  Cnt   Score   Error  Units
AbstractVsInterfaceBenchmark.abstractClassMethod  avgt    5   2.315 ± 0.052  ns/op
AbstractVsInterfaceBenchmark.interfaceMethod      avgt    5   2.302 ± 0.048  ns/op

好吧，好吧，好吧……我们看到了什么？区别是……鼓声……几乎可以忽略不计！两种方法的执行时间大约都是2.3纳秒。这比你说“过早优化”还要快！

这意味着什么？

在我们下结论之前，让我们分析一下：

  1. 现代JVM很聪明：得益于JIT编译和其他优化，抽象类和接口之间的性能差异在简单方法调用中已经变得很小。
  2. 不总是关于速度：选择抽象类和接口的主要依据应该是设计考虑，而不是微观优化。
  3. 上下文很重要：我们的基准测试非常简单。在具有更复杂层次结构或频繁调用的真实场景中，你可能会看到略有不同的结果。

何时使用什么

所以，如果性能不是决定因素，那该如何选择？这里有一个快速指南：

选择抽象类的情况：

  • 你需要在方法之间维护状态
  • 你想为子类提供一个通用的基础实现
  • 你正在设计密切相关的类

选择接口的情况：

  • 你想为不相关的类定义一个契约
  • 你需要多重继承（记住，Java不允许多重类继承）
  • 你正在为灵活性和未来扩展设计

情节加深：默认方法

但是等等，还有更多！自Java 8以来，接口可以有默认方法。让我们看看它们的表现如何：


@Benchmark
public void defaultInterfaceMethod() {
    interfaceCar.honk();
}

与我们之前的基准测试一起运行可能会显示默认方法比抽象类方法稍慢，但同样，我们谈论的是纳秒级的差异。这种差异不太可能对真实应用程序产生显著影响。

优化提示

虽然在抽象类和接口之间进行微观优化可能不值得你花时间，但这里有一些保持代码快速的通用提示：

  • 保持简单：过于复杂的类层次结构可能会减慢速度。追求设计优雅与简单之间的平衡。
  • 注意菱形问题：在接口中使用默认方法时，你可能会遇到歧义问题。必要时要明确。
  • 分析，不要猜测：始终在你的具体用例中测量性能。JMH很棒，但也可以考虑使用VisualVM等工具来获得更广泛的视角。

总结

最终，抽象类和接口之间的性能差异不是你代码的瓶颈。专注于良好的设计原则、可读性和可维护性。根据你的架构需求进行选择，而不是基于纳米级的优化。

记住，过早优化是万恶之源（或至少是其中的一大部分）。使用合适的工具来完成工作，让JVM负责挤出最后几纳秒。

思考的食粮

在你离开之前，思考一下：如果我们在纳秒级上斤斤计较，我们是否在解决正确的问题？也许真正的性能提升在于我们的算法、数据库查询或网络调用中。保持大局观，愿你的代码始终高效！

编码愉快，愿你的抽象始终合乎逻辑，接口清晰！