Image native de Graalvm: compilation de votre application Java à l'avance

L'image native GraalVM convertit les applications Java en fichiers exécutables natifs via la compilation AOT, en résolvant les problèmes de démarrage lent et une utilisation élevée de la mémoire en mode JVM traditionnel. 1. La vitesse de démarrage est une milliseconde, adaptée aux serveurs et aux microservices; 2. L'utilisation de la mémoire est réduite de 30% à 70%; 3. Le package de déploiement est plus petit et il n'est pas nécessaire de transporter JVM; 4. La sécurité est améliorée et la surface d'attaque est réduite. Remarque lorsque vous utilisez: 1. Réflexion, proxy dynamique, etc. doivent être configurés explicitement; 2. Les fichiers de ressources doivent être inclus via Resource-Config.json; 3. Le chargement dynamique des classes est limité; 4. Certaines bibliothèques qui s'appuient sur l'ASM ou génèrent dynamiquement des bytecodes sont incompatibles. Les cadres traditionnels tels que Spring Boot 3, Quarkus et MicronAut sont bien pris en charge et conviennent aux scénarios à froid sensibles à la botte et sont un mode de fonctionnement important de Java dans des environnements natifs de cloud modernes.

Java est connu depuis longtemps pour être "écrit une fois, exécuter partout", grâce à la compilation instantanée de JVM (JIT) et à l'exécution de bytecode multiplateforme. Cependant, comme les exigences en matière de vitesse de démarrage, d'empreinte mémoire et d'efficacité de déploiement natif du cloud deviennent de plus en plus élevées, le modèle JVM traditionnel a commencé à apparaître "lourd". La technologie d'image native de GraalVM est conçue pour résoudre ces problèmes - il vous permet de compiler les applications Java à l'avance (à l'avance, AOT) en tant qu'exécutable local.

Qu'est-ce que l'image native?

L'image native est un outil fourni par GRAALVM qui peut compiler directement Java Bytecode (fichiers .class ou pots) dans des fichiers exécutables natifs spécifiques à la plate-forme (tels que ELF sur Linux, Mach-O sur macOS, PE sur Windows). Ce processus se produit avant l'exécution de l'application, c'est-à-dire la compilation AOT.

Contrairement au processus de démarrage JVM traditionnel:

• JVM traditionnel : Java → Bytecode → Explication JVM Compilation JIT → Code machine (runtime)
• Image native : Java → Bytecode → Compilation d'image native → Fichier exécutable natif (démarrage, code machine)

Le résultat est un fichier binaire séparé qui ne s'appuie plus sur JVM, démarre très rapidement et a une empreinte de mémoire plus bas.

Pourquoi utiliser l'image native?

1. Vitesse de démarrage extrêmement rapide

Le temps de démarrage du miroir natif est généralement au niveau de la milliseconde , ce qui convient particulièrement aux scénarios sensibles au début du froid tels que le serveur sans serveur (comme AWS Lambda), les microservices, les outils CLI, etc.

Par exemple: il a fallu à l'origine 3 à 5 secondes pour démarrer une application de démarrage à ressort, mais cela ne prend peut-être 50 ms qu'après avoir utilisé l'image native.

2. Utilisation de la mémoire inférieure

Sans les frais généraux d'exécution de JVM, la mémoire hors têtes est plus contrôlable. Les miroirs natifs utilisent généralement 30% à 70% de mémoire moins que les applications JVM équivalentes.

3. Packages de déploiement plus petits

Bien que les fichiers binaires générés puissent être plus grands que JAR, ils n'ont pas besoin d'emballer le JVM et la taille globale de l'image du conteneur est plus petite, adaptée aux déploiements légers.

4. Plus sûr (une certaine mesure)

Sans JVM, la surface d'attaque est réduite; Et le code a été déterminé au moment de la compilation, et les comportements dynamiques tels que la réflexion sont limités, ce qui aide à l'audit de sécurité.

Comment utiliser l'image native?

Condition préalable

• Installez GRAALVM (recommandé d'utiliser graalvm-ce ou graalvm-ee )
• Installer l'outil native-image (via gu install native-image )

 # Exemple: JDK en utilisant Graalvm
exporter java_home = / path / to / graalvm
GU installer natif-image

Compiler une application Java simple

 // helloworld.java
classe publique Helloworld {
    public static void main (String [] args) {
        System.out.println ("Hello, Native World!");
    }
}

Étapes de compilation:

 javac helloworld.java
HELLOWORLD IMAGE natif

Générez le fichier exécutable helloworld et exécutez-le directement:

 ./Bonjour le monde
# Sortie: Bonjour, monde natif!

Notes et restrictions

L'image native n'est pas omnipotente. Il a quelques limitations clés, principalement en raison de la nature de la compilation AOT:

1. Réflexion, proxy dynamique et JNI doivent être configurés explicitement

AOT ne peut pas prédire quelles classes seront utilisées reflétées lors de la compilation, de sorte que le compilateur doit être raconté via le fichier de configuration.

Façons courantes:

• Annotation avec @RegisterForReflection
• Fournir un fichier reflect-config.json

 // refléter-config.json
[
  {
    "nom": "com.example.myclass",
    "Méthodes": [
      {"name": "<init>", "ParameterTypes": []}
    ]]
  }
]]

2. Le fichier de ressources doit être explicitement inclus

Les fichiers de configuration, les modèles, les ressources internationales, etc. ne seront pas automatiquement emballés et doivent être spécifiés via resource-config.json .

3. Le chargement dynamique des classes est limité

Class.forName() , les classes de chargement dynamique ClassLoader ne sont pas disponibles au moment de l'exécution (sauf si connu au moment de la compilation).

4. Certaines bibliothèques sont incompatibles

Par exemple: Groovy, JRuby, certains frameworks qui utilisent ASM pour générer des bytecode dynamiquement, peuvent avoir des erreurs dans l'image native.

Intégration avec les cadres traditionnels

Heureusement, de nombreux frameworks Java modernes prennent déjà en charge l'image native:

• Spring Boot : Prise en charge de Spring Native Project (maintenant intégré dans Spring Boot 3)
• Quarkus : La priorité par défaut est de prendre en charge la compilation native, connue sous le nom de "Born for Cloud Native"
• MicronAut : gère beaucoup de logique au moment de la compilation, naturellement adapté à AOT

Par exemple: pour créer une application native à l'aide de Quarkus, juste:

 mvn quarkus: build -dquarkus.package.type = natif

---

Résumer

L'image native GraalVM permet aux applications Java de se débarrasser du "fardeau" de JVM et apporte un saut qualitatif dans la vitesse de démarrage, l'efficacité de la mémoire et le déploiement léger. Bien qu'il ait des limites aux caractéristiques réflexes et dynamiques, ces points de douleur sont progressivement traités à mesure que l'écosystème mûrit (en particulier le support de Spring Boot 3 Quarkus Micronaut).

Si votre application est:

• Fonction de microservice ou de serveur
• Outils CLI
• Scénarios sensibles au démarrage à froid

Ensuite, cela vaut la peine d'essayer l'image native. Il ne s'agit pas de remplacer le JVM, mais fournit à Java un autre mode de fonctionnement qui convient plus aux environnements cloud modernes .

Fondamentalement, c'est tout - la compilation AOT n'est plus le "futur", il a déjà commencé à fonctionner en production.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!