Java-Startzeiten optimieren

Wann lohnt sich schneller Java-Start überhaupt?

Startzeiten begleiten Java-Entwickler seit Jahren. Wer schon einmal eine Spring-Boot-Anwendung in einem Container hochgefahren hat und dabei zusehen konnte, wie die Sekunden vergehen, kennt das Problem.

Aber zuerst die ehrliche Frage: Wann ist das wirklich relevant? Aus meiner Erfahrung in drei Fällen:

• Serverless-Computing — wo jeder Cold Start direkt auf die Antwortzeit durchschlägt.
• Viele kleine Services, die in einem Cluster nebeneinander laufen — schnellerer Start heißt weniger Rechenkapazität, die nur fürs Hochfahren reserviert wird.
• Hochverfügbarkeit unter Last — wenn ein Pod ausfällt und ein neuer in unter einer Sekunde übernehmen muss.

Am 12. November war ich bei atra im Stuttgarter Office zu Gast und habe einen Abend lang die verschiedenen Ansätze zur Optimierung von Java-Startzeiten systematisch durchgearbeitet — vom einfachen Tuning bis hin zu grundlegenden Paradigmenwechseln.

Rechnet sich das? Ein Beispiel

Bevor wir uns in technische Details stürzen: Was bringt schnellerer Start in Euro?

Stellen wir uns einen Kubernetes-Cluster vor, in dem zwölf Java-Services laufen. Heute braucht jeder Service rund 30 Sekunden bis zur Bereitschaft. Damit Updates ohne Downtime ausgerollt werden können und Lastspitzen nicht zur Wartezeit führen, sind sechs Server allein als „Reserve” reserviert.

Halbieren wir die Startzeit, lässt sich diese Reserve auf drei Server reduzieren. Drei eingesparte Server, drei Jahre Laufzeit, mit Strom, Wartung und Lizenzen — das summiert sich auf rund 50.000 Euro.

Dem stehen Aufwände gegenüber: Rund 46.000 Euro für Engineering-Zeit, Tooling und Build-Pipeline-Umstellung. Netto bleibt nicht viel — aber der Cluster ist schlanker, die Deploys reagibler, und der Effekt skaliert mit der Servicezahl. Bei doppelt so vielen Services kippt die Rechnung deutlich auf die Investitionsseite.

Die Faustregel: Schneller Start ist kein Selbstzweck. Er rechnet sich, wo viele Instanzen, häufige Deploys oder lastabhängige Skalierung zusammenkommen.

Die Hebel, von einfach bis radikal

Es gibt keinen einzelnen Schalter. Die Optionen reihen sich entlang einer Achse — auf der einen Seite minimaler Aufwand mit moderatem Effekt, auf der anderen Seite radikale Umstellung mit dramatischen Gewinnen, aber auch Einschränkungen.

Spring Boot Tuning

Der erste und einfachste Hebel. Lazy Initialization, nicht benötigte Auto-Configurations deaktivieren, Actuator-Endpoints reduzieren, Component-Scan-Pfade einschränken. Klingt banal, bringt aber bei großen Anwendungen erstaunlich viel — oft 20 bis 40 Prozent in wenigen Tagen Arbeit. Mein Tipp: Bevor irgendwer „GraalVM” sagt, hier eine Woche investieren.

Class Data Sharing (CDS) und Project Leyden

CDS gibt es seit JDK 5, ist aber bei vielen Teams unbekannt. Es erlaubt, Klassendaten in ein Shared Archive auszulagern, das beim Start direkt in den Speicher gemappt wird. Seit JDK 13 schließt Application CDS auch eigene Klassen ein. Effekt: zehn bis dreißig Prozent schnellerer Start, ohne Codeänderung.

Project Leyden ist Oracles langfristige Antwort. Idee: Arbeit von der Laufzeit in die Build-Phase verschieben — „Shifting Left”. Noch in Entwicklung, aber die Richtung stimmt: AOT-Caches, Pre-Resolved Constants, Pre-Linked Classes. Wer heute schon CDS nutzt, profitiert später ohne weiteren Aufwand.

Project CRaC

Ein anderer Ansatz: Statt schneller zu starten, wird der Zustand einer bereits laufenden JVM als Checkpoint gesichert und kann in Millisekunden wiederhergestellt werden. Besonders interessant für Serverless. Der Haken: Verbindungen, offene Files und Secrets müssen sauber serialisiert werden — die Anwendung muss CRaC-aware sein.

GraalVM Native Image

Der radikalste Schritt. Die Anwendung wird Ahead-of-Time in ein natives Binary kompiliert. Ergebnis: Startzeiten im einstelligen Millisekundenbereich und deutlich geringerer Speicherverbrauch. Der Preis: eingeschränkte Reflection-Unterstützung (Spring funktioniert, kostet aber Konfiguration), längere Build-Zeiten, ein verändertes Runtime-Verhalten — und keine Live-JIT-Optimierung mehr.

Die zentrale Erkenntnis

Je schneller der Start, desto größer der Aufwand und die Einschränkungen. Diese Trade-off-Gerade gilt durchgängig — von Spring Boot Tuning bis Native Image. Welche Stelle sich für ein Projekt lohnt, hängt am konkreten Lastprofil, an der Service-Anzahl und an der Bereitschaft, Architektur-Entscheidungen früh festzulegen.

Selbst nachvollziehen

Wer die Optionen direkt vergleichen möchte: Ich habe einen Fork des Spring-PetClinic-Projekts vorbereitet, in dem die verschiedenen Startup-Optimierungen als separate Branches angelegt sind — von der Baseline über CDS bis GraalVM Native Image. Repository: github.com/ksilz/spring-petclinic.

Die kompletten Slides des Vortrags inklusive aller Benchmark-Zahlen gibt es hier: