In diesem Artikel erf\u00e4hrst du:<\/p>\n\n\n\n
Java-Anwendungen sind zur Laufzeit extrem flexibel. Klassen k\u00f6nnen dynamisch geladen und entladen werden. Dynamische Kompilierung, Optimierung und Deoptimierung machen Java-Programme so schnell wie C-Code \u2013 oder schneller. Und durch Reflection sind Frameworks wie Jakarta EE, Spring Boot, Quarkus, Helidon oder Micronaut \u00fcberhaupt erst m\u00f6glich.<\/p>\n\n\n\n
Doch diese Vorteile haben ihren Preis:<\/p>\n\n\n\n
Beim Start einer Anwendung m\u00fcssen Hunderte Gro\u00dfe Backend-Anwendungen k\u00f6nnen so mehrere Sekunden oder sogar Minuten ben\u00f6tigen, bis sie vollst\u00e4ndig gestartet sind.<\/p>\n\n\n\n Viele der im vorherigen Abschnitt beschriebenen Initialisierungsarbeiten sind bei jedem Anwendungsstart dieselben.<\/p>\n\n\n\n Im Rahmen von Project Leyden<\/a> wird daher daran gearbeitet, m\u00f6glichst viele dieser sich immer wiederholenden Aufgaben bereits vor<\/em> dem Start einer Anwendung auszuf\u00fchren.<\/p>\n\n\n\n Durch JDK Enhancement Proposal 483<\/a> wurden in Java 24 <\/a>die ersten Fr\u00fcchte dieser Arbeit ver\u00f6ffentlicht: Klassen k\u00f6nnen nun nach dem Lesen, Parsen, Laden und Linken in einer Bin\u00e4rdatei \u2013 dem AOT-Cache<\/em> \u2013 gespeichert werden und sind damit bei zuk\u00fcnftigen Starts derselben Anwendung deutlich schneller in geladenem und gelinktem Zustand verf\u00fcgbar. Die JDK-Entwickler:innen haben Startzeit-Reduzierungen um bis zu 42 % gemessen.<\/p>\n\n\n\n Durch JDK Enhancement Proposal 514<\/a>, Ahead-of-Time Command-Line Ergonomics<\/em>, wurde in Java 25<\/a> die Generierung des AOT-Caches vereinfacht \u2013 statt zwei Schritten muss nur noch einer ausgef\u00fchrt werden.<\/p>\n\n\n\n Durch JDK Enhancement Proposal 515<\/a>, Ahead-of-Time Method Profiling<\/em>, wurde \u2013 ebenfalls in Java 25 \u2013 der AOT-Cache um Statistiken \u00fcber Methodenaufrufe erweitert, so dass die JVM die am h\u00e4ufigsten aufgerufenen Methoden (\u201eHotspots\u201c) schon kurz nach dem Start kompilieren kann, statt erst zur Laufzeit Profildaten sammeln zu m\u00fcssen. Dadurch erreicht die Anwendung ihre Spitzenleistung schneller \u2013 gemessen wurde eine Reduzierung der Aufw\u00e4rmzeit (Warmup) um 19 %.<\/p>\n\n\n\n Und in Java 26<\/a> kam mit JDK Enhancement Proposal 516<\/a>, Ahead-of-Time Object Caching with Any GC<\/em>, ein weiterer Baustein hinzu: Bis dahin wurden die vorinitialisierten Objekte des AOT-Caches in einem GC-spezifischen Format direkt in den Speicher gemappt \u2013 das funktionierte nicht mit jedem Garbage Collector. Seit Java 26 k\u00f6nnen die Objekte stattdessen in einem GC-neutralen Format sequenziell geladen werden. Dadurch l\u00e4sst sich der AOT-Cache nun mit jedem Garbage Collector nutzen \u2013 einschlie\u00dflich des Low-Latency-Collectors ZGC, der bisher au\u00dfen vor war.<\/p>\n\n\n\n Um den Programmstart durch AOT Class Loading & Linking zu beschleunigen, m\u00fcssen wir drei Schritte (bzw. zwei, dazu unten mehr) durchf\u00fchren:<\/p>\n\n\n\n Das h\u00f6rt sich komplizierter an als es ist. Im Folgenden f\u00fchre ich dich Schritt f\u00fcr Schritt anhand einer Beispielanwendung durch diese Schritte bis hin zum beschleunigten Start der Anwendung.<\/p>\n\n\n\n Ich zeige dir in diesem Abschnitt an einer kleinen Anwendung Schritt f\u00fcr Schritt, wie Ahead-of-Time Class Loading & Linking funktioniert.<\/p>\n\n\n\n Wir benutzen dazu ein ganz einfaches Demo-Programm, das lediglich die aktuelle Zeit anzeigt.<\/p>\n\n\n\n.jar<\/code>-Dateien entpackt und Tausende .class<\/code>-Dateien in den Speicher geladen, analysiert und verkn\u00fcpft werden. Der statische Initialisierungscode von Klassen muss ausgef\u00fchrt werden, und Frameworks wie Jakarta EE und Spring m\u00fcssen den Code nach Annotationen scannen, Beans instanziieren und Konfigurationscode ausf\u00fchren.<\/p>\n\n\n\nWie kann der Start von Anwendungen beschleunigt werden?<\/h2>\n\n\n\n
Wie funktioniert Ahead-of-Time Class Loading & Linking?<\/h2>\n\n\n\n
\n
Noch einmal Schritt f\u00fcr Schritt zum Mitmachen<\/h3>\n\n\n\n