Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Personnalisation du comportement de démarrage de l’environnement d’exécution Java pour les fonctions Lambda

Cette page décrit les paramètres spécifiques aux fonctions Java dans AWS Lambda. Vous pouvez utiliser ces paramètres pour personnaliser le comportement de démarrage de l'exécution Java. Cela permet de réduire le temps de latence et d'améliorer les performances globales de la fonction, sans avoir à modifier le code.

Présentation de la variable d’environnement JAVA_TOOL_OPTIONS

Sur Java, Lambda prend en charge la variable d'environnement JAVA_TOOL_OPTIONS pour définir des variables de ligne de commande supplémentaires dans Lambda. Vous pouvez utiliser cette variable d'environnement de différentes manières, par exemple pour personnaliser les paramètres de compilation par niveaux. L'exemple suivant montre comment utiliser la variable d'environnement JAVA_TOOL_OPTIONS pour ce cas d'utilisation.

Exemple : personnalisation des paramètres de compilation par niveaux

La compilation par niveaux est une fonctionnalité de la JVM (Java Virtual Machine). Vous pouvez utiliser des paramètres de compilation hiérarchisés spécifiques pour tirer le meilleur parti des compilateurs de la JVM just-in-time (JIT). Généralement, le compilateur C1 est optimisé pour un démarrage rapide. Le compilateur C2 est optimisé pour obtenir les meilleures performances globales, mais il utilise également plus de mémoire et prend plus de temps pour y parvenir. Il existe cinq niveaux différents de compilation par niveaux. Au niveau 0, la JVM interprète le bytecode Java. Au niveau 4, la JVM utilise le compilateur C2 pour analyser les données de profilage collectées lors du démarrage de l'application. Au fil du temps, elle surveille l'utilisation du code pour identifier les meilleures optimisations.

La personnalisation du niveau de compilation à plusieurs niveaux peut vous aider à optimiser les performances de vos fonctions Java. Pour les petites fonctions qui s'exécutent rapidement, le réglage de la compilation hiérarchisée au niveau 1 peut contribuer à améliorer les performances de démarrage à froid en faisant en sorte que la JVM utilise le compilateur C1. Ce paramètre produit rapidement du code natif optimisé, mais il ne génère aucune donnée de profilage et n'utilise jamais le compilateur C2. Pour les fonctions plus volumineuses nécessitant des calculs intensifs, le fait de définir la compilation hiérarchisée au niveau 4 maximise les performances globales au détriment d'une consommation de mémoire supplémentaire et d'un travail d'optimisation supplémentaire lors des premiers appels après le provisionnement de chaque environnement d'exécution Lambda.

Pour les environnements d'exécution Java 11 et inférieurs, Lambda utilise les paramètres de compilation hiérarchisée par défaut de la JVM. Pour Java 17 et Java 21, Lambda configure la JVM pour arrêter la compilation hiérarchisée au niveau 1 par défaut. À partir de Java 25, Lambda arrête toujours la compilation hiérarchisée au niveau 1 par défaut, sauf en cas d'utilisation SnapStart ou de provisionnement de la concurrence, auquel cas les paramètres JVM par défaut sont utilisés. Cela améliore les performances SnapStart et la simultanéité provisionnée sans entraîner de pénalité de démarrage à froid, car la compilation à plusieurs niveaux est effectuée en dehors du chemin d'appel dans ces cas. Pour optimiser cet avantage, vous pouvez utiliser l'amorçage, c'est-à-dire l'exécution de chemins de code lors de l'initialisation de la fonction pour déclencher le JIT avant de prendre le SnapStart snapshot ou lorsque les environnements d'exécution de la concurrence provisionnée sont préprovisionnés. Pour plus d'informations, consultez le billet de blog Optimisation des performances de démarrage à froid de AWS Lambda à l'aide de stratégies d'amorçage avancées avec. SnapStart

Exemple : personnalisation du comportement de GC à l'aide de JAVA_TOOL_OPTIONS

Les exécutions Java 11 utilisent le récupérateur de mémoire (GC) Serial pour la récupération de mémoire. Par défaut, les exécutions Java 17 utilisent également le GC Serial. Toutefois, avec Java 17, vous pouvez également utiliser la variable d'environnement JAVA_TOOL_OPTIONS pour modifier le GC par défaut. Vous pouvez choisir entre le GC Parallel et le GC Shenandoah.

Par exemple, si votre charge de travail utilise plus de mémoire et de multiples CPUs, pensez à utiliser le Parallel GC pour de meilleures performances. Vous pouvez le faire en ajoutant ce qui suit à la valeur de votre variable d'environnement JAVA_TOOL_OPTIONS :

-XX:+UseParallelGC

Si votre charge de travail comporte de nombreux objets de courte durée, vous pouvez bénéficier d'une réduction de la consommation de mémoire en activant le mode générationnel du ramasse-miettes Shenandoah introduit dans Java 25. Pour ce faire, ajoutez ce qui suit à la valeur de votre variable d'JAVA_TOOL_OPTIONSenvironnement :

-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational

Patch Log4j pour Log4Shell

Les environnements d'exécution Lambda pour Java 8, 11, 17 et 21 incluent un correctif pour atténuer la vulnérabilité Log4Shell (CVE-2021-44228) dans Log4j, un framework de journalisation Java populaire. Ce correctif entraîne une surcharge des performances de démarrage à froid. Si vous utilisez une version corrigée de Log4j (version 2.17.0 ou ultérieure), vous pouvez désactiver ce correctif pour améliorer les performances de démarrage à froid. Pour désactiver le correctif, définissez la variable d'AWS_LAMBDA_DISABLE_CVE_2021_44228_PROTECTIONenvironnement surtrue.

À partir de Java 25, les environnements d'exécution Lambda n'incluent plus le correctif Log4Shell. Vous devez vérifier que vous utilisez Log4j version 2.17.0 ou ultérieure.

Ahead-of-Time (AOT) et caches CDS

À partir de Java 25, le moteur d'exécution Lambda inclut un cache Ahead-of-Time (AOT) pour le client d'interface d'exécution Java (RIC), un composant d'exécution qui interroge activement les événements provenant de l'API Lambda Runtime. Cela améliore les performances de démarrage à froid.

Les caches AOT sont spécifiques à une version de machine virtuelle Java. Lorsque Lambda met à jour le runtime géré, il met également à jour le cache AOT du RIC. Toutefois, si vous déployez vos propres caches AOT, ceux-ci peuvent être invalidés ou entraîner un comportement inattendu après une mise à jour d'exécution. Nous recommandons donc vivement de ne pas utiliser les caches AOT lorsque vous utilisez des environnements d'exécution gérés. Pour utiliser les caches AOT, vous devez déployer vos fonctions à l'aide d'images de conteneur.

Les caches AOT ne peuvent pas être utilisés avec les caches de partage de données de classe (CDS). Si vous déployez des caches CDS dans votre fonction Lambda, Lambda désactive le cache AOT.