Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Passen Sie das Startverhalten der Java-Laufzeit für Lambda-Funktionen an

Diese Seite beschreibt spezifische Einstellungen für Java-Funktionen in AWS Lambda. Sie können diese Einstellungen verwenden, um das Startup-Verhalten der Java-Laufzeit anzupassen. Dies kann die allgemeine Funktionslatenz reduzieren und die Gesamtleistung der Funktionen verbessern, ohne dass Code geändert werden muss.

Grundlegendes zur Umgebungsvariablen JAVA_TOOL_OPTIONS

In Java unterstützt Lambda die Umgebungsvariable JAVA_TOOL_OPTIONS, um zusätzliche Befehlszeilenvariablen in Lambda festzulegen. Sie können diese Umgebungsvariable auf verschiedene Arten verwenden, z. B. um die Einstellungen für die gestufte Kompilierung anzupassen. Im nächsten Beispiel wird gezeigt, wie die Umgebungsvariable JAVA_TOOL_OPTIONS für diesen Anwendungsfall verwendet wird.

Beispiel: Einstellungen für die gestufte Kompilierung anpassen

Die gestufte Kompilierung ist ein Feature der virtuellen Java-Maschine (JVM). Sie können spezielle Einstellungen für die gestufte Kompilierung verwenden, um die Just-in-Time (JIT)-Compiler der JVM optimal zu nutzen. In der Regel ist der C1-Compiler für eine schnelle Startzeit optimiert. Der C2-Compiler ist für die beste Gesamtleistung optimiert, benötigt aber auch mehr Speicher und es dauert länger, bis er erreicht ist.

Die gestufte Kompilierung umfasst 5 verschiedene Stufen. Auf Stufe 0 interpretiert die JVM Java-Bytecode. Auf Stufe 4 verwendet die JVM den C2-Compiler, um die beim Startup der Anwendung gesammelten Profildaten zu analysieren. Im Laufe der Zeit überwacht sie die Code-Nutzung, um die besten Optimierungen zu identifizieren.

Das Anpassen der mehrstufigen Kompilierungsebene kann Ihnen helfen, die Leistung Ihrer Java-Funktion zu optimieren. Bei kleinen Funktionen, die schnell ausgeführt werden, kann das Setzen der mehrstufigen Kompilierung auf Stufe 1 dazu beitragen, die Kaltstartleistung zu verbessern, da die JVM den C1-Compiler verwendet. Diese Einstellung erzeugt schnell optimierten systemeigenen Code, generiert jedoch keine Profilerstellungsdaten und verwendet niemals den C2-Compiler. Bei größeren, rechenintensiven Funktionen maximiert die Einstellung der mehrstufigen Kompilierung auf Stufe 4 die Gesamtleistung auf Kosten von zusätzlichem Speicherverbrauch und zusätzlicher Optimierungsarbeit bei den ersten Aufrufen nach der Bereitstellung jeder Lambda-Ausführungsumgebung.

Für Java 11-Laufzeiten und darunter verwendet Lambda die standardmäßigen mehrstufigen JVM-Kompilierungseinstellungen. Für Java 17 und Java 21 konfiguriert Lambda die JVM so, dass die mehrstufige Kompilierung standardmäßig auf Level 1 beendet wird. Ab Java 25 stoppt Lambda die mehrstufige Kompilierung standardmäßig immer noch auf Level 1, außer wenn Parallelität SnapStart oder Provisioned verwendet wird. In diesem Fall werden die Standard-JVM-Einstellungen verwendet.

Dadurch wird die Leistung bei Parallelität SnapStart und Provisioning verbessert, ohne dass es zu einer Kaltstartstrafe kommt, da die mehrstufige Kompilierung in diesen Fällen außerhalb des Aufrufpfads durchgeführt wird. Um diesen Vorteil zu maximieren, können Sie während der Funktionsinitialisierung das Priming — die Ausführung von Codepfaden — verwenden, um JIT auszulösen, bevor der SnapStart Snapshot erstellt wird, oder wenn die Provisioned Concurrency-Ausführungsumgebungen vorab bereitgestellt sind. Weitere Informationen finden Sie im Blogbeitrag Optimieren der Kaltstartleistung von AWS Lambda mithilfe fortschrittlicher Priming-Strategien mit. SnapStart

Beispiel: Anpassen des GC-Verhaltens mit JAVA_TOOL_OPTIONS

Java-11-Laufzeiten verwenden den Serial Garbage Collector (GC) für Garbage Collection. Standardmäßig verwenden Java-17-Laufzeiten auch den Serial GC. Mit Java 17 können Sie jedoch auch die Umgebungsvariable JAVA_TOOL_OPTIONS verwenden, um den Standard-GC zu ändern. Sie können zwischen dem Parallel GC und dem Shenandoah GC wählen.

Wenn Ihre Workload beispielsweise mehr Arbeitsspeicher und mehrere CPUs benötigt, sollten Sie erwägen, den Parallel GC zu verwenden, um eine bessere Leistung zu erzielen. Hängen Sie dazu Folgendes an den Wert Ihrer Umgebungsvariablen JAVA_TOOL_OPTIONS an:

-XX:+UseParallelGC

Wenn Ihr Workload viele kurzlebige Objekte enthält, können Sie von einem geringeren Speicherverbrauch profitieren, indem Sie den Generationsmodus des Shenandoah-Garbage Collectors aktivieren, der in Java 25 eingeführt wurde. Hängen Sie dazu Folgendes an den Wert Ihrer Umgebungsvariablen an: JAVA_TOOL_OPTIONS

-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational

Log4j-Patch für Log4Shell

Die Lambda-Laufzeiten für Java 8, 11, 17 und 21 enthalten einen Patch zur Minderung der Log4Shell-Sicherheitslücke (CVE-2021-44228) in Log4j, einem beliebten Java-Logging-Framework. Dieser Patch verursacht einen Leistungsüberschuss beim Kaltstart. Wenn Sie eine gepatchte Version von Log4j (Version 2.17.0 oder höher) verwenden, können Sie diesen Patch deaktivieren, um die Kaltstartleistung zu verbessern. Um den Patch zu deaktivieren, setzen Sie die Umgebungsvariable auf. AWS_LAMBDA_DISABLE_CVE_2021_44228_PROTECTION true

Ab Java 25 enthalten Lambda-Runtimes den Log4Shell-Patch nicht mehr. Sie müssen überprüfen, ob Sie Log4j Version 2.17.0 oder höher verwenden.

Ahead-of-Time (AOT) und CDS-Caches

Ab Java 25 enthält die Lambda-Laufzeit einen Ahead-of-Time (AOT) -Cache für den Java Runtime Interface Client (RIC), eine Laufzeitkomponente, die aktiv von der Lambda Runtime API nach Ereignissen abfragt. Dies verbessert die Kaltstartleistung.

AOT-Caches sind spezifisch für einen JVM-Build. Wenn Lambda die verwaltete Laufzeit aktualisiert, aktualisiert es auch den AOT-Cache für den RIC. Wenn Sie jedoch Ihre eigenen AOT-Caches bereitstellen, werden diese möglicherweise ungültig oder führen nach einem Runtime-Update zu unerwartetem Verhalten. Wir empfehlen daher dringend, keine AOT-Caches zu verwenden, wenn Sie verwaltete Laufzeiten verwenden. Um AOT-Caches zu verwenden, sollten Sie Ihre Funktionen mithilfe von Container-Images bereitstellen.

AOT-Caches können nicht mit Class Data Sharing (CDS) -Caches verwendet werden. Wenn Sie CDS-Caches in Ihrer Lambda-Funktion bereitstellen, deaktiviert Lambda den AOT-Cache.