Abwägungen beim Native Image

Native Image ist leistungsfähig, aber nicht kostenlos. Es tauscht die Anpassungsfähigkeit der JVM zur Laufzeit gegen schnellen Start und geringen Speicherbedarf. Wenn Sie diese Zielkonflikte verstehen, können Sie besser entscheiden, wann der Wechsel zu nativer Ausführung sinnvoll ist.

Der wichtigste Vorteil: Eine native Binärdatei überspringt das Laden von Klassen, die Bytecode-Verifizierung und das JIT-Aufwärmen. Sie kann innerhalb weniger Millisekunden statt nach Hunderten von Millisekunden starten — ein entscheidender Vorteil für CLIs und serverlose Funktionen.

Kein JIT-Compiler, keine Profiling-Datenstrukturen und ein vorab berechneter Image-Heap sorgen dafür, dass ein nativer Prozess deutlich weniger RAM benötigt. Dadurch können Sie mehr Instanzen pro Container betreiben und die Kapazität stark reduzieren.

Die entscheidende Abwägung. Der JIT optimiert anhand von aktiven Laufzeitprofilen. Eine langfristig laufende JVM kann daher einen höheren Spitzendurchsatz erreichen als eine AOT-Binärdatei, die beim Build ohne Laufzeitinformationen optimiert wurde. Bei dauerhaft stark ausgelasteten Workloads kann die JVM weiterhin überlegen sein.

GraalVM verringert den Durchsatzabstand mit PGO: Erstellen Sie ein instrumentiertes Image, führen Sie einen repräsentativen Workload aus, um Profile zu sammeln, und erstellen Sie das Image anschließend anhand dieser Profile neu. Die AOT-Binärdatei ähnelt dann für diesen Workload einem aufgewärmten JIT.

Das Erstellen eines nativen Images ist langsam und speicherintensiv — bei großen Anwendungen werden dafür mehrere Minuten CPU-Zeit und mehrere Gigabyte RAM benötigt. Dadurch verlängern sich CI-Pipelines im Vergleich zu einem schnellen jar-Build.

Reflection, Proxys und Ressourcen benötigen Metadaten, wie bereits zuvor erläutert. Code, der stark auf das Laden von Klassen zur Laufzeit oder auf die Generierung von Bytecode angewiesen ist, lässt sich ohne Änderungen möglicherweise nur schwer oder gar nicht vollständig nativ kompilieren.

Einige JVM-Tools unterscheiden sich im nativen Modus. Standardmäßige JVMTI-Agents und bestimmte Profiler lassen sich nicht auf dieselbe Weise verbinden; stattdessen verwenden Sie native-image-spezifisches Monitoring oder Sampling. Planen Sie Ihre Observability-Strategie entsprechend.

Native Image bringt eigene Garbage Collector mit: einen einfachen Serial GC und in einigen Editionen G1. Für sehr große Heaps kann die vollständige Auswahl an Garbage Collectors der JVM eine bessere Latenz bieten. Stimmen Sie den Garbage Collector auf die Heap-Größe und die Anforderungen an Pausenzeiten Ihres Workloads ab.

• Serverless-Funktionen, die auf null Instanzen herunterskalieren.
• CLI-Tools, bei denen die Startzeit entscheidend ist.
• Microservices in dicht gepackten Containern.
• Kurzlebige Batch-Jobs.

• Lang laufende, durchsatzkritische Services, bei denen die Spitzenleistung des JIT entscheidend ist.
• Anwendungen mit starkem dynamischem Klassenladen oder Bytecode-Generierung.
• Workloads, die auf JVMTI-basierten Tools beruhen.

Testen Sie Ihr Verständnis der Abwägungen bei Native Image.

Sie haben die Abwägungen bei Native Image abgewogen:

• Vorteile: Startzeiten im Millisekundenbereich und ein geringer Speicherbedarf.
• Kosten: potenziell geringerer Spitzendurchsatz, langsame Builds, Metadaten für dynamische Funktionen und Unterschiede bei den Tools.
• PGO verringert den Durchsatzabstand durch profilgesteuerte Neubuilds.
• Native Image eignet sich für CLIs, Serverless-Anwendungen und dicht gepackte Microservices.
• Die JVM eignet sich für lang laufende, durchsatzkritische und stark dynamische Anwendungen.