Asignación de memoria JVM

Hola a todos! Queremos coincidir la traducción del material de hoy con el lanzamiento de un nuevo hilo en el curso Java Developer , que comienza mañana. Bueno, empecemos.

JVM puede ser una bestia compleja. Afortunadamente, la mayor parte de esta complejidad está oculta bajo el capó, y nosotros, como desarrolladores de aplicaciones y responsables de la implementación, a menudo no tenemos que preocuparnos mucho por eso. Aunque debido a la creciente popularidad de la tecnología para implementar aplicaciones en contenedores, vale la pena prestar atención a la asignación de memoria en la JVM.



Dos tipos de memoria

La JVM divide la memoria en dos categorías principales: heap y no heap. Un montón es una pieza de memoria JVM con la que los desarrolladores están más familiarizados. Los objetos creados por la aplicación se almacenan aquí. Permanecen allí hasta que el recolector de basura los retire. Por lo general, el tamaño de almacenamiento dinámico que usa la aplicación varía según la carga actual.

La memoria fuera del montón se divide en varias áreas. En HotSpot, puede usar el mecanismo de seguimiento de memoria nativa (NMT) para explorar las áreas de esta memoria. Tenga en cuenta que aunque NMT no rastrea el uso de toda la memoria nativa ( por ejemplo, no rastrea la asignación de memoria nativa por código de terceros ), sus capacidades son suficientes para la mayoría de las aplicaciones típicas de Spring. Para usar NMT, ejecute la aplicación con la -XX:NativeMemoryTracking=summary y usando jcmd VM.native_memory summary ver información sobre la memoria utilizada.

Veamos el uso de NMT como ejemplo de nuestro viejo amigo Petclinic . El siguiente diagrama muestra el uso de la memoria JVM de acuerdo con los datos de NMT (menos su propia sobrecarga de NMT) al iniciar Petclinic con un tamaño de -Xmx48M dinámico máximo de 48 MB ( -Xmx48M ):



Como puede ver, la memoria fuera del montón representa la mayor parte de la memoria JVM utilizada, y la memoria del montón es solo una sexta parte del total. En este caso, son aproximadamente 44 MB (de los cuales 33 MB se usaron inmediatamente después de la recolección de basura). El uso de memoria fuera del montón totalizó 223 MB.

Áreas de memoria nativa

Espacio de clase comprimido : se utiliza para almacenar información sobre clases cargadas. Limitado al parámetro MaxMetaspaceSize . Una función del número de clases que se han cargado.

Nota del traductor

Por alguna razón, el autor escribe sobre el espacio de clase comprimido, y no sobre el área de clase completa. El área de espacio de clase comprimido es parte del área de clase, y el parámetro MaxMetaspaceSize limita el tamaño del área de clase completa, no solo el espacio de clase comprimido. Para limitar el "espacio de clase comprimido", se utiliza el parámetro CompressedClassSpaceSize .

Desde aquí :
Si UseCompressedOops está activado y se usa UseCompressedClassesPointers , entonces se usan dos áreas lógicamente diferentes de memoria nativa para los metadatos de la clase ...
Se asigna una región para estos punteros de clase comprimidos (los desplazamientos de 32 bits). El tamaño de la región se puede establecer con CompressedClassSpaceSize y es de 1 gigabyte (GB) de forma predeterminada ...
MaxMetaspaceSize aplica a la suma del espacio de clase comprimido comprometido y el espacio para los metadatos de la otra clase

Si el parámetro UseCompressedOops está UseCompressedOops y UseCompressedOops usa UseCompressedOops , entonces UseCompressedOops usan dos áreas lógicamente diferentes de memoria nativa para los metadatos de la clase ...

Para punteros comprimidos, se asigna un área de memoria (compensaciones de 32 bits). CompressedClassSpaceSize puede establecer el tamaño de esta área y, de forma predeterminada, es de 1 GB ...
El parámetro MaxMetaspaceSize se refiere a la suma del área del puntero comprimido y el área para otros metadatos de clase.

• Subproceso: la memoria utilizada por subprocesos en la JVM. La función del número de subprocesos en ejecución.
• Caché de código: la memoria utilizada por JIT para ejecutarlo. Una función del número de clases que se han cargado. Limitado a ReservedCodeCacheSize . Puede reducir la configuración de JIT, por ejemplo, deshabilitando la compilación escalonada.
• GC (recolector de basura): almacena los datos utilizados por el recolector de basura. Depende del recolector de basura utilizado.
• Símbolo: almacena caracteres como nombres de campo, firmas de métodos y cadenas internados. El uso excesivo de la memoria de caracteres puede indicar que las líneas están demasiado internados.
• Interno: almacena otros datos internos que no están incluidos en ninguna de las otras áreas.

Las diferencias

En comparación con un montón, la memoria fuera del montón cambia menos bajo carga. Una vez que la aplicación haya cargado todas las clases que se utilizarán y el JIT esté completamente calentado, todo pasará a un estado estable. Para ver una disminución en el uso del espacio de clases comprimido , el recolector de basura debe eliminar el cargador de clases que cargó las clases. Esto era común en el pasado cuando las aplicaciones se implementaban en contenedores de servlets o servidores de aplicaciones (el recolector de basura eliminó el cargador de clases de aplicaciones cuando la aplicación se eliminó del servidor de aplicaciones), pero esto rara vez ocurre con los enfoques modernos para la implementación de aplicaciones.

Configurar JVM

Configurar la JVM para usar eficientemente la RAM disponible no es fácil. Si ejecuta la JVM con el parámetro -Xmx16M y no espera -Xmx16M más de 16 MB de memoria, obtendrá una sorpresa desagradable.

Un área interesante de la memoria JVM es el caché de código JIT. Por defecto, HotSpot JVM usará hasta 240 MB. Si el caché de código es demasiado pequeño, el JIT puede no tener suficiente espacio para almacenar sus datos y, como resultado, se reducirá el rendimiento. Si el caché es demasiado grande, entonces la memoria puede desperdiciarse. Al determinar el tamaño de un caché, es importante tener en cuenta su efecto tanto en el uso de la memoria como en el rendimiento.

Cuando se ejecuta en un contenedor Docker, las últimas versiones de Java ahora son conscientes de las limitaciones de memoria del contenedor y están tratando de cambiar el tamaño de la memoria JVM en consecuencia. Desafortunadamente, a menudo se asigna mucha memoria fuera del montón y no hay suficiente en el montón. Supongamos que tiene una aplicación ejecutándose en un contenedor con 2 procesadores y 512 MB de memoria disponible. Desea manejar más carga de trabajo y aumentar el número de procesadores a 4 y la memoria a 1 GB. Como discutimos anteriormente, el tamaño del almacenamiento dinámico generalmente varía con la carga, y la memoria fuera del almacenamiento dinámico cambia significativamente menos. Por lo tanto, esperamos que la mayoría de los 512 MB adicionales se asignen al montón para manejar el aumento de carga. Desafortunadamente, por defecto, la JVM no hará esto y distribuirá memoria adicional de manera más o menos uniforme entre la memoria en el montón y fuera del montón.

Afortunadamente, el equipo de CloudFoundry tiene un amplio conocimiento de la asignación de memoria en la JVM. Si descarga aplicaciones a CloudFoundry, el paquete de compilación le aplicará automáticamente este conocimiento. Si no está utilizando CloudFoudry o desea obtener más información sobre cómo configurar JVM, se recomienda leer la descripción de la tercera versión de la calculadora de memoria de Java buildpack .

¿Qué significa esto para la primavera?

El equipo de Spring pasa mucho tiempo pensando en el rendimiento y el uso de la memoria, considerando la posibilidad de usar la memoria tanto en el montón como fuera del mismo. Una forma de limitar el uso de memoria fuera del montón es hacer que las partes del marco sean lo más versátiles posible. Un ejemplo de esto es usar Reflection para crear e inyectar dependencias en los beans de su aplicación. Mediante el uso de Reflection, la cantidad de código marco que usa permanece constante, independientemente de la cantidad de beans en su aplicación. Para optimizar el tiempo de inicio, utilizamos el caché en el montón, borrando este caché después de que se complete el inicio. El recolector de basura puede limpiar fácilmente la memoria del montón para proporcionar más memoria disponible para su aplicación.

Tradicionalmente, esperamos sus comentarios sobre el material.