SUNNYVALE, Kalifornien, 6. Oktober 2026 – Azul, der vertrauenswürdige Marktführer für Enterprise Java in einer KI-geprägten Welt, gibt bekannt, dass Azul Prime nun eine zwei- bis fünfmal schnellere Anwendungs-Warm-up-Zeit im Vergleich zu Standard-OpenJDK bietet. Dadurch können Unternehmen schlankere, dynamischere und kosteneffizientere Java-Bereitstellungen betreiben.
Diese Verbesserung ist dem Cloud Native Compiler des Azul Optimizer Hub zu verdanken, einer speziellen Funktion von Azul Prime. Diese zentralisiert und speichert die Just-in-Time-Kompilierungen (JIT) über eine ganze Flotte von Java Virtual Machines (JVMs) hinweg zwischen, anstatt es jeder JVM zu überlassen, die Leistung isoliert zu optimieren. Neue Instanzen, die für eine bestimmte Anwendung oder einen Microservice gestartet werden, erhalten beim Start gestreamten, vollständig optimierten kompilierten Code, noch bevor sie Datenverkehr entgegennehmen. Dadurch erreichen Anwendungen ihre volle Leistung weitaus schneller als mit Standard-OpenJDK.
Der flottenweite Warm-up-Aufwand
Der Übergang zu containerbasierten Cloud-Anwendungen und -Diensten, die sich dynamisch skalieren lassen, in Verbindung mit der deutlich schnelleren Bereitstellung von Code durch den Einsatz von KI-Codegenerator-Tools macht ein effizientes JVM-Warm-up wichtiger denn je. Fast zwei Drittel der Organisationen mit Kubernetes-Einsatz skalieren mittlerweile automatisch – ein Anstieg gegenüber den rund 55 Prozent vor weniger als zwei Jahren, wie aus dem Bericht „2025 State of Containers and Serverless“ von Datadog hervorgeht.[1] Gleichzeitig luden Entwickler im Jahr 2025 fast 1 Milliarde Codeänderungen (Commits) auf GitHub hoch – ein Anstieg von 25 Prozent gegenüber dem Vorjahr –, da KI-Codegeneratoren das Tempo des Wandels beschleunigen, wie aus dem „Octoverse“-Bericht 2025 von GitHub hervorgeht.[2]
Bei herkömmlichen Bereitstellungen hat keine JVM einer Anwendung Kenntnis davon, was andere Instanzen in der Flotte bereits gelernt und optimiert haben. Daher führt jede neue Instanz zunächst langsameren, weniger optimierten Code aus, bis sie im Laufe der Ausführung erkennt, dass bestimmte Codesegmente häufig genug verwendet werden, um optimiert zu werden – was zu dem bekannten „Warm-up“-Problem beim Starten neuer Instanzen führt. Skalierung behebt dieses Problem nicht: Unabhängig davon, wie viele Instanzen einer Flotte bereits aufgewärmt sind, startet die nächste Instanz „kalt“.
Teams umgehen den Warm-up-Aufwand heute entweder durch eine Überdimensionierung der Rechenkapazität, um den langsamen Warm-up-Prozess abzufangen, oder indem sie nach jeder Bereitstellung einfach eine Phase mit verminderter Leistung und erhöhter Latenz in Kauf nehmen. Diese Umgehungslösungen führen entweder zu höheren Kosten durch ungenutzte Kapazitäten, zu Umsatzverlusten durch entgangene Transaktionen beim Start der Anwendungen oder zu einer schlechten Kundenerfahrung aufgrund spürbarer Verlangsamungen. Diese Vorgehensweise wird immer teurer: Die CPU-Überprovisionierung in Kubernetes – also die Lücke zwischen der bereitgestellten Kapazität und dem tatsächlichen Bedarf der Workloads – stieg laut dem „2026 State of Kubernetes Optimization Report“ von Cast AI im Jahresvergleich von 40 auf 69 Prozent.[3]
Lösung des Warm-up-Problems in Java-Flotten
Das Warm-up-Problem ist eine seit langem bestehende Herausforderung bei Java-Bereitstellungen. Azul bietet bereits seit 2014 Funktionen zur Bewältigung an, als das Unternehmen ReadyNow einführte, um Warm-up-Verzögerungen bei einzelnen JVMs in latenzempfindlichen Workloads zu beheben. Im Jahr 2023 erweiterte Azul dies um den „ReadyNow Orchestrator“, der das beste Warm-up-Optimierungsprofil über die gesamte JVM-Flotte einer Anwendung hinweg überwacht, daraus lernt und es jeder Instanz bereitstellt, die es anfordert. Der Cloud Native Compiler treibt diese flottenweite Intelligenz nun noch weiter voran: Anstatt kompilierten Code auf Anfrage bereitzustellen, liefert er ihn bereits beim Start vorausschauend aus. So fährt jede Instanz zwei- bis fünfmal schneller hoch als mit Standard-OpenJDK. Mit dieser neuen Funktion erhält jede JVM-Instanz einer Anwendung oder eines Microservices nun:
- Vorausschauende Bereitstellung: Anstatt kompilierten Code Methode für Methode anzufordern und zu empfangen, erhält eine Instanz beim Start als einzigen Datenstrom den vollständig optimierten Code, dessen Bedarf auf der Grundlage früherer Instanz-Starts in der gesamten JVM-Flotte einer Anwendung vorhergesagt wurde.
- Vorausschauende Installation: Anstatt häufig genutzte Codepfade durch langsame Codeinterpretation und -promotion zu ermitteln, installiert die neu gestartete Instanz Code, den die Anwendungsflotte bereits optimiert hat – abgeleitet aus der erfolgreichen Ausführung identischer Workloads –, sodass diese Optimierungen bereits vorhanden sind, bevor der tatsächliche Datenverkehr eintrifft, und nicht erst darauf reagieren.
- Keine Änderungen an der Anwendung: Es sind keine Neuprogrammierung, Neukompilierung oder Neugestaltung der Architektur für Anwendungen oder Microservices erforderlich; eine einfache Konfigurationseinstellung in Azul Prime mit dem Cloud Native Compiler ermöglicht diese spezielle Funktion.
Das Ergebnis ist, dass neue Instanz die bisherigen Arbeitsergebnisse der Anwendungsflotte übernimmt, anstatt diese neu zu erlernen. So erreicht sie deutlich schneller als bei Standard-OpenJDK-Bereitstellungen die volle Produktionsgeschwindigkeit. Im Gegensatz zu Ahead-of-Time-Ansätzen sammelt der Cloud Native Compiler Optimierungen über eine gesamte Live-Flotte hinweg. Er lernt und optimiert kontinuierlich, während die Anwendung läuft – der Nutzen vervielfacht sich also, je mehr Instanzen der Flotte in Betrieb sind. Keine andere JVM oder OpenJDK-Distribution.
Was ein schnelleres Warm-up ermöglicht
Das deutlich schnellere Erreichen der vollen Geschwindigkeit – anstatt Instanz für Instanz hochzufahren – verändert die Wirtschaftlichkeit des Betriebs einer Java-Flotte in großem Maßstab in zweierlei Hinsicht:
- Reibungsloseres Auto-Scaling, geringere Cloud-Kosten: Java-Teams halten in der Regel zusätzliche „Warm-Standby“-Instanzen als Kapazität bereit, die ausschließlich dazu dient, die Zeit zu überbrücken, die eine neue Instanz zum Aufwärmen benötigt. Wenn neue Instanzen deutlich schneller produktiv sind, kann dieser benötigte Spielraum drastisch reduziert, wenn nicht sogar ganz eliminiert werden. Betreiber, die statisch überprovisionieren oder geplantes Auto-Scaling nutzen, können nun möglicherweise dynamisch skalieren und warme Instanzen schnell online schalten, um die Standby-Rechenkapazität drastisch zu reduzieren.
- Reaktionsschnelles Kundenerlebnis: Bei Standard-OpenJDK-Bereitstellungen kommt es bei einer „kalten“ JVM – auf der die ersten Transaktionen mit langsamerem, weniger optimiertem Code ausgeführt werden – am ehesten zu Zeitüberschreitungen, langen Latenzzeiten oder Störungen bei Kundenanfragen. Durch die erhebliche Reduzierung der Warm-up-Verzögerung verhält sich jede neu skalierte oder neu bereitgestellte Instanz in der Regel bereits ab der ersten Anfrage wie der Rest der optimierten Flotte, sei es bei einem Traffic-Anstieg oder einer routinemäßigen Neubereitstellung. Dadurch wird die Leistung von Anfang an verbessert und ein nahtloses Kundenerlebnis geschaffen.
Das Ergebnis ist besonders wichtig für Unternehmen, bei denen Spitzenleistung bereits ab der allerersten Anfrage unverzichtbar ist: Betrugserkennung, Echtzeit-Werbeauktionen, digitale Zahlungen, Multiplayer-Spiele und E-Commerce.
Ein schlüsselfertiger Ansatz für Vertriebspartner
Mit dieser neuen Funktion in Azul Prime mit dem Cloud Native Compiler können Vertriebspartner von Azul ihren Kunden erhebliche Kosteneinsparungen bieten, unter anderem durch ihre Professional-Services und Managed-Deployment-Angebote. Das alles erfolgt auf Basis der bereits vorhandenen Java-Anwendungsinfrastruktur und ohne die Notwendigkeit, Anwendungen neu zu schreiben oder die Architektur zu überarbeiten.
„Teams haben sich so lange mit dem langsamen Hochfahren der JVM abgefunden, dass sie es als gegeben hinnehmen, überzudimensionieren und die automatische Skalierung zu vermeiden, nur um das Problem zu verbergen“, sagte Scott Sellers, Co-Founder und CEO von Azul. „Azul Prime mit dem Cloud Native Compiler behebt dieses Problem. Eine neue Anwendungsinstanz übernimmt die Compiler-Optimierungen, die ihre Flotte bereits gelernt und ausgeführt hat, anstatt von Null anzufangen. Man muss nicht mehr für jede einzelne Instanz die ‚Aufwärmkosten‘ tragen und verkürzt so die Zeit, die eine bestimmte Anwendungsinstanz benötigt, um ihre volle Leistung zu erreichen.“
Der Cloud Native Compiler ist als Teil von
Um zu erfahren, wie der Cloud Native Compiler von Azul Prime die Aufwärmzeit in Ihrer gesamten Java-Flotte verkürzen kann, besuchen Sie die Seite zum Cloud Native Compiler.
FAQs:
Warum startet eine Java-Anwendungsinstanz langsam, auch wenn sich der Code nicht geändert hat?
Die Java Virtual Machine (JVM) ist für die Ausführung des Anwendungscodes verantwortlich. Beim Start beginnt sie, den Code zu interpretieren und (im Laufe der Zeit) zu kompilieren, um eine optimierte Ausführung zu erreichen. Dieser „Kaltstart“-Prozess dauert eine gewisse Zeit, und jede Instanz in der Anwendungsflotte durchläuft diesen langsamen Prozess, selbst wenn andere Instanzen bereits mit voller Geschwindigkeit laufen. Der Cloud Native Compiler von Azul Prime reduziert diesen Leistungsverlust, indem er den bereits kompilierten Code einer Anwendungsflotte beim Start an jede neue Instanz überträgt, sodass diese im Vergleich zu Standard-OpenJDK zwei- bis fünfmal schneller ihre volle Geschwindigkeit erreicht.
Wie kann ich vermeiden, Cloud-Kapazitäten übermäßig bereitzustellen, nur um die langsame Aufwärmphase der JVM auszugleichen?
Eine Überdimensionierung und das Vorhalten zusätzlicher Warm-Standby-Instanzen ist eine Notlösung für eine zu langsam hochfahrende JVM, keine dauerhafte Behebung. Azul Prime geht die Ursache an: Neue Anwendungsinstanzen übernehmen den kompilierten Code ihrer Flotte sofort beim Start, sodass Teams die ungenutzte Kapazität, die sie bisher zur Kaschierung von Hochfahrproblemen vorhielten, reduzieren oder sogar ganz eliminieren können.
Gibt es eine Möglichkeit, die JIT-Kompilierung über die gesamte Flotte einer Anwendung hinweg gemeinsam zu nutzen, anstatt sie bei jedem Start einer JVM zu wiederholen?
Ja. Der Cloud Native Compiler von Azul Prime speichert den kompilierten Code, den die Flotte einer Anwendung erzeugt, in einem zentralen Dienst zwischen; seine neueste Funktion überträgt diesen Code beim Start proaktiv an jede neue Instanz, wodurch die Zeit, die eine Instanz benötigt, um ihre volle Leistung zu erreichen, weiter verkürzt wird.
Was ist der schnellste Weg, um bei einer horizontal skalierten Java-Anwendung eine konsistente Leistung und Latenz über alle Instanzen hinweg zu erzielen?
Die Konsistenz über den gesamten JVM-Bestand einer Anwendung hängt davon ab, wie schnell neue Instanzen hochfahren und ihre voll optimierte Leistung erreichen. Azul Prime mit dem Cloud Native Compiler reduziert die Hochlaufzeit einer Instanz erheblich, indem neue Instanzen die im gesamten Bestand gesammelten Optimierungen installieren, bevor tatsächlicher Datenverkehr eintrifft – im Gegensatz zu herkömmlichen Bereitstellungen, bei denen jede Instanz unabhängig hochgefahren wird, was zu schlechter Leistung und Latenz während dieser Hochlaufphase führt.
Kann ich die Java-Aufwärmleistung verbessern, ohne den Anwendungscode zu ändern?
Ja. Das flottenweite Streaming von kompiliertem Code in Azul Prime wird durch eine einzige Konfigurationsänderung an einer Cloud Native Compiler-Bereitstellung aktiviert: Es ist keine Neuprogrammierung, Neukompilierung oder Umstrukturierung der Anwendung erforderlich.
Über Azul
Azul ist der vertrauenswürdige Marktführer im Bereich Enterprise Java für die heutige KI- und Cloud-first Welt. Seine Open-Source-basierte Java-Plattform ermöglicht es Unternehmen, den gesamten Java-Lebenszyklus zu optimieren, um die Leistung zu beschleunigen, die Sicherheit zu erhöhen, Lizenz- und Cloud-Kosten zu senken und die Produktivität der Entwickler zu steigern. Azul unterstützt geschäftskritische Systeme für 37 Prozent der Fortune-100-Unternehmen, 50 Prozent der Forbes-Top-10-Marken mit dem höchsten Markenwert weltweit und die zehn weltweit führenden Finanzhandelsunternehmen. Weitere Informationen finden Sie unter azul.com und folgen Sie @azulsystems.
# # #
Pressekontakt:
PER Connect
Daniela Fichtl / Nicole Stadtmüller
Hofmannstraße 54
81379 München
Telefon: + 49 89 17959 18-0
E-Mail: [email protected]
[1] Datadog: Der Stand der Dinge bei Containern und Serverless, 6. November 2025.
[2] GitHub: „ Octoverse: Jede Sekunde kommt ein neuer Entwickler zu GitHub hinzu, während KI TypeScript auf Platz 1 bringt .“ Der GitHub-Blog, 28. Oktober 2025.
[3] Cast AI: Bericht zum Stand der Kubernetes-Optimierung 2026
@Rebekah Dumouchelle Ist jede neue Instanz in der Flotte mit dem Cloud Native Compiler verbunden? Wäre das präziser und genauer?
@Rebekah Dumouchelle Hält dies im Vergleich zu den zentralisierten Diensten von IBM Semeru und anderen Wettbewerbern stand?
Nach unseren Recherchen gibt es keine OpenJDK-Distribution, die einen flottenweiten Anwendungsbereich mit kumulativen, sich verstärkenden Verbesserungen verbindet.
Wir erheben derzeit keine Gebühren für CNC oder OptHub – @Rebekah Dumouchelle Du kannst das noch einmal bei Karen bestätigen lassen.
Bestätigt.