Bevor wir mit Benchmarks um uns werfen wie mit Konfetti, lassen Sie uns unser Gedächtnis auffrischen, was diese beiden unterscheidet:

  • Abstrakte Klassen: Der OOP-Schwergewichtler. Kann Zustand, Konstruktoren und sowohl abstrakte als auch konkrete Methoden haben.
  • Interfaces: Der Leichtgewichtler. Traditionell zustandslos, aber seit Java 8 haben sie mit Standard- und statischen Methoden aufgerüstet.

Hier ein schneller Vergleich, um in Schwung zu kommen:


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

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

Das Performance-Rätsel

Nun, Sie könnten denken: "Sicher, sie sind unterschiedlich, aber spielt das leistungstechnisch wirklich eine Rolle?" Nun, mein neugieriger Programmierer, genau das wollen wir herausfinden. Lassen Sie uns JMH starten und sehen, was passiert.

JMH: Der Benchmark-Flüsterer

JMH (Java Microbenchmark Harness) ist unser treuer Begleiter für diese Leistungsuntersuchung. Es ist wie ein Mikroskop für die Ausführungszeit Ihres Codes und hilft uns, die Fallstricke naiver Benchmarks zu vermeiden.

Um mit JMH zu beginnen, fügen Sie dies zu Ihrer pom.xml hinzu:


<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>

Einrichten des Benchmarks

Lassen Sie uns einen einfachen Benchmark erstellen, um den Methodenaufruf bei abstrakten Klassen und Interfaces zu vergleichen:


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();
    }
}

Den Benchmark ausführen

Nun, lassen Sie uns diesen Benchmark ausführen und sehen, was wir erhalten. Denken Sie daran, wir messen die durchschnittliche Ausführungszeit in Nanosekunden.


# Den Benchmark ausführen
mvn clean install
java -jar target/benchmarks.jar

Die Ergebnisse sind da!

Nach dem Ausführen des Benchmarks (Ergebnisse können je nach Ihrer spezifischen Hardware und JVM variieren) könnten Sie etwas wie das Folgende sehen:


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

Nun, nun, nun... Was haben wir hier? Der Unterschied ist... Trommelwirbel... praktisch vernachlässigbar! Beide Methoden werden in etwa 2,3 Nanosekunden ausgeführt. Das ist schneller, als Sie "vorzeitige Optimierung" sagen können!

Was bedeutet das?

Bevor wir zu Schlussfolgerungen springen, lassen Sie uns das aufschlüsseln:

  1. Moderne JVMs sind schlau: Dank JIT-Kompilierung und anderer Optimierungen ist der Leistungsunterschied zwischen abstrakten Klassen und Interfaces bei einfachen Methodenaufrufen minimal geworden.
  2. Es geht nicht immer um Geschwindigkeit: Die Wahl zwischen abstrakten Klassen und Interfaces sollte in erster Linie auf Designüberlegungen basieren, nicht auf Mikro-Optimierungen.
  3. Der Kontext zählt: Unser Benchmark ist super einfach. In realen Szenarien mit komplexeren Hierarchien oder häufigeren Aufrufen könnten Sie leicht unterschiedliche Ergebnisse sehen.

Wann was verwenden

Wenn Leistung also nicht der entscheidende Faktor ist, wie wählen Sie dann? Hier ist ein kurzer Leitfaden:

Wählen Sie abstrakte Klassen, wenn:

  • Sie Zustand über Methoden hinweg beibehalten müssen
  • Sie eine gemeinsame Basisimplementierung für Unterklassen bereitstellen möchten
  • Sie eng verwandte Klassen entwerfen

Wählen Sie Interfaces, wenn:

  • Sie einen Vertrag für nicht verwandte Klassen definieren möchten
  • Sie Mehrfachvererbung benötigen (denken Sie daran, Java erlaubt keine Mehrfachvererbung von Klassen)
  • Sie für Flexibilität und zukünftige Erweiterungen entwerfen

Die Handlung verdichtet sich: Standardmethoden

Aber warten Sie, es gibt noch mehr! Seit Java 8 können Interfaces Standardmethoden haben. Schauen wir, wie sie sich schlagen:


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

Wenn Sie dies zusammen mit unseren vorherigen Benchmarks ausführen, könnte sich zeigen, dass Standardmethoden etwas langsamer sind als Methoden in abstrakten Klassen, aber wir sprechen hier von Nanosekunden. Der Unterschied wird reale Anwendungen wahrscheinlich nicht signifikant beeinflussen.

Optimierungstipps

Während Mikro-Optimierungen zwischen abstrakten Klassen und Interfaces möglicherweise nicht Ihre Zeit wert sind, hier einige allgemeine Tipps, um Ihren Code schnell zu halten:

  • Halten Sie es einfach: Übermäßig komplexe Klassenhierarchien können die Dinge verlangsamen. Streben Sie ein Gleichgewicht zwischen elegantem Design und Einfachheit an.
  • Achten Sie auf Diamantprobleme: Mit Standardmethoden in Interfaces können Sie auf Mehrdeutigkeitsprobleme stoßen. Seien Sie bei Bedarf explizit.
  • Profilieren, nicht raten: Messen Sie die Leistung immer in Ihrem spezifischen Anwendungsfall. JMH ist großartig, aber ziehen Sie auch Tools wie VisualVM für ein umfassenderes Bild in Betracht.

Die Quintessenz

Am Ende des Tages ist der Leistungsunterschied zwischen abstrakten Klassen und Interfaces nicht der Engpass Ihres Codes. Konzentrieren Sie sich auf gute Designprinzipien, Lesbarkeit und Wartbarkeit. Wählen Sie basierend auf Ihren architektonischen Bedürfnissen, nicht auf Nano-Optimierungen.

Denken Sie daran, vorzeitige Optimierung ist die Wurzel allen Übels (oder zumindest ein guter Teil davon). Verwenden Sie das richtige Werkzeug für die Aufgabe und lassen Sie die JVM die letzten Nanosekunden herausholen.

Denkanstoß

Bevor Sie gehen, denken Sie darüber nach: Wenn wir uns über Nanosekunden streiten, lösen wir dann die richtigen Probleme? Vielleicht warten die echten Leistungsgewinne in unseren Algorithmen, Datenbankabfragen oder Netzwerkaufrufen. Behalten Sie das große Ganze im Auge, und möge Ihr Code immer leistungsfähig sein!

Viel Spaß beim Programmieren, und mögen Ihre Abstraktionen immer logisch und Ihre Interfaces klar sein!