AppCDS
Esta guía de referencia explica cómo habilitar Application Class Data Sharing en sus aplicaciones Quarkus.
¿Qué es el uso compartido de datos de clases de aplicaciones (AppCDS)?
Application Class Data Sharing is a JVM feature that helps reduce the startup time and memory footprint of a JVM application. This is achieved by having the JVM create a pre-processed shared archived of classes that are loaded at startup time. As these classes are loaded every time the application starts, AppCDS is a conceptually simple way of improving the application startup time, without the application itself having to be coded or configured in a specific way. How much of an improvement depends on many factors, such as the number of classes loaded, the underlying hardware, etc.
Generación de AppCDS Vanilla
El principal inconveniente de crear AppCDS manualmente para una aplicación es que su generación requiere lanzar la aplicación con banderas especiales y obtener el archivo en un paso previo al despliegue de la aplicación en producción.
| The exact process depends on the JVM version being used, as newer JVM have incrementally made the process easier. |
This fact makes AppCDS difficult to use for real world deployments where a CI pipeline is responsible for building and deploying applications.
AppCDS en Quarkus
Creación del archivo
Quarkus hace que la generación de AppCDS sea tan sencilla como establecer la propiedad de configuración quarkus.package.jar.appcds.enabled en true. Para una aplicación Quarkus de ejemplo que utilice Maven (suponiendo que esté ubicada en /tmp/code-with-quarkus), el archivo AppCDS puede generarse simplemente construyendo la aplicación de la siguiente manera:
./mvnw package -Dquarkus.package.jar.appcds.enabled=trueCuando finalice la compilación, la salida contendrá (entre otras cosas) lo siguiente:
[INFO] [io.quarkus.deployment.pkg.steps.AppCDSBuildStep] Launching AppCDS creation process.
[INFO] [io.quarkus.deployment.pkg.steps.AppCDSBuildStep] AppCDS successfully created at: '/tmp/code-with-quarkus/target/quarkus-app/app-cds.jsa'.
[INFO] [io.quarkus.deployment.pkg.steps.AppCDSBuildStep] To ensure they are loaded properly, run the application jar from its directory and also add the '-XX:SharedArchiveFile=app-cds.jsa' JVM flag.
Moreover, make sure to use the exact same Java version (x.y.z) to run the application as was used to build it.Si echamos un vistazo a /tmp/code-with-quarkus/target/quarkus-app, entre los otros archivos, vemos app-cds.jsa, que es el archivo AppCDS generado.
Utilización del archivo
El uso del archivo se realiza mediante la bandera -XX:SharedArchiveFile. Sin embargo, se aplican algunas advertencias:
-
Las rutas de acceso al archivo jar de Quarkus y al archivo AppCDS deben ser exactamente las mismas que las utilizadas por Quarkus para crear el archivo.
-
La versión de la JVM utilizada para ejecutar la aplicación debe ser exactamente la misma que la utilizada para construir la aplicación Quarkus.
Asumiendo que estamos usando la misma JVM para ejecutar la aplicación que la que usamos para construir la aplicación, podemos lanzar la aplicación así:
cd target/quarkus-app
java -XX:SharedArchiveFile=app-cds.jsa -jar quarkus-run.jar|
La JVM es resistente. Enfrentada a una situación en la que el fichero de archivo no es utilizable (por la razón que sea), simplemente desactivará la función AppCDS. Si se desea simplemente detener la ejecución cuando el archivo no es utilizable, se puede utilizar la siguiente invocación de línea de comandos: |
|
Dado lo que se mencionó anteriormente acerca de cómo la aplicación necesita ser lanzada para que el archivo sea construido, surge la pregunta de cómo Quarkus se ocupa de esta situación. La respuesta es que en el momento de construir la aplicación, justo después de construir el archivo de la aplicación, Quarkus lanza la aplicación, pero sólo se ejecutan las partes del proceso de lanzamiento que son seguras. Más concretamente, la aplicación se ejecuta hasta los pasos que realmente abren sockets o ejecutan la lógica de la aplicación. This results in an archive generation process that, on one hand, is completely safe, but on the other hand, is unable to archive every single class that the application might need at boot time. As a result, users are expected to get a slightly more effective archive if they manually go through the hoops of generating the AppCDS archive. |
|
AppCDS ha mejorado significativamente en las últimas versiones del JDK. Esto significa que, para garantizar las mejores mejoras posibles, asegúrese de que sus proyectos se dirigen a la versión de Java más alta posible (idealmente 17 o 21). |
|
Starting with JDK 24, the JVM provides an evolution of the class-data sharing in the form of the AOT cache. If you are building an application that will target JDK 25+ you can take advantage of this feature by adding the following system property when packaging your application: The result of using these flags is the creation of an AOT cache file named You can use this AOT cache when launching the application like so: |
Generate the AOT cache from integration tests
Although Quarkus can generate an AOT cache file without ever running the production application, the file will not be optimal as the application was never exercised against any load. To alleviate this,
Quarkus can use the existing testsuite of tests annotated with @QuarkusIntegrationTest to create an AOT cache file.
See the corresponding section in the Testing Guide for more details.
Uso en contenedores
When building container images using the quarkus-container-image-jib extension, Quarkus automatically takes care of all the steps needed to generate the archive and make it usable at runtime in the container.
This way, by simply setting quarkus.package.jar.appcds.enabled to true, containers using the generated image can benefit from a slight reduction in startup time and memory usage.
You may see that Quarkus starts a container to generate the AppCDS archive.
It does this to ensure that the Java version of the build aligns with that of the generated container image.
It is possible to opt out of this by setting quarkus.package.jar.appcds.use-container to false.
In that case, it is your responsibility to ensure that the Java version that will run the Quarkus application matches that of the machine building it.
