Subiendo la escalera: análisis y comprensión de JVM

Análisis y comprensión de JVM

1. Diagrama de estructura del modelo de memoria de la máquina virtual JVM

Explicación del modelo:

Parte púrpura: pila (hilo), pila de método local, contador de programa.

• Pila: Es la pila de memoria que solemos decir, el usuario almacena las variables ordinarias temporales generadas durante la ejecución del hilo;
• Pila de métodos locales: Java es un lenguaje de alto nivel lanzado en 1995, pero el lenguaje C que ha existido antes juega un papel insustituible en la capa inferior.
  Por ejemplo, usando Thread.start (), el método start () es un "método nativo", y la firma del método se modifica con la palabra clave nativa para ejecutar la función del lenguaje C en **. Dll.
• Contador de programa: cuando hay más de un hilo, el hilo se suspenderá y luego se ejecutará debido a la fragmentación de la CPU o la suspensión manual del hilo. Luego hay un contador que registra el "número de línea de código" en el código fuente de la JVM. Este número de línea continúa ejecutando tareas de hilo;

Parte amarilla: área de montón y método (metaespacio).

• Montón: objeto de almacenamiento del usuario;
• Área de método: los usuarios almacenan constantes, variables estáticas e información de clase. jdk8 pasó a llamarse Metaspace. PD: Las constantes y variables estáticas almacenadas aquí son externas al método y no pertenecen a las variables en la pila de subprocesos.

El interior del montón se puede dividir en dos grandes partes: generación joven y generación anterior;

Generación joven: Eden y Survivor
Generación anterior: Old
Survivor tiene dos áreas: S1, S2, switch GC ROOTS almacenamiento de objetos durante la recuperación de GC

Relación de asignación de memoria Eden: Survivor: Old = 1/3 * 4/5: 1/3 * 1/10: 1/3 * 1/10: 2/3 = 8/30: 1/30: 1/30: 20 / 30

Pila de hilos

• Contador de programa: el código "número de línea" dentro del método después de que el código se compila en el código jvm, se usa para registrar la ejecución del código actual a qué línea; cuando el puntero de la CPU cambia a otro hilo y luego vuelve, continúa ejecutando el código desde la posición del contador ；
• Pila de hilos (FILO): estructura de pila, una pila de hilos;
• Marco de pila: cada función tiene un marco de pila;
• Tabla de variables locales: variables declaradas dentro del método;
• Pila de operandos: Variables creadas temporalmente en el método. Por ejemplo: a = 1, donde 1 pertenece al tipo de datos básico y se almacena directamente en la pila de operandos. Después de ser asignado a una variable local, se extrae;
• Enlace dinámico:
• Salida del método: registra la posición devuelta después de que se ejecuta el método;

2. Mecanismo de recolección de basura de JVM

Mecanismo de recolección de basura

1. El nuevo objeto en el código se almacena en el área de Edén. En este momento, agregue la edad de generación del objeto a este objeto y establézcalo en 0, como: Estudiante [0].
2. Después de un período de tiempo en el que el área del Edén está casi llena (puede establecer las condiciones usted mismo), será reciclada por el menor gc . Los objetos " GC Roots " como punto de partida, comenzando desde estos nodos hacia abajo, la referencia del objeto de búsqueda, los objetos encontrados se marcan como objetos que no son basura . Luego, el gc menor copia los objetos marcados como no basura en el área S1 del área Superviviente, y su edad de generación +1, como: Estudiante [1], y luego borra directamente todos los objetos en el área Edén.
3. Después de un período de tiempo, cuando el área del Edén esté llena nuevamente, el área del Edén y el área de Supervivientes donde se almacena el objeto se reciclarán. De acuerdo con la cadena GC Roots, los objetos que no son basura se mueven a áreas donde no hay objetos en Survivor, y la edad de generación de objetos es +1, y luego el área de Eden y otra área de Survivor se vacían.
4. Cuando la edad de generación del objeto alcanza el nivel 15, aparece un objeto de memoria grande o la memoria del objeto excede el 50% del área S0, el objeto se moverá directamente a la edad avanzada y no habrá escaneo gc menor.
5. Generalmente, después de que los objetos de la vejez estén llenos en unas pocas semanas o meses, el gc completo eliminará los objetos de basura en la vejez según GC Roots.
6. Si el gc completo no puede limpiar los objetos en la vejez, y la vejez está completa, el nuevo almacenamiento interno activará el error OOM: Out Of Memery.

Nodo raíz GC Roots: variables locales de la pila de subprocesos, variables estáticas, variables de la pila de métodos local, etc.
Edad generacional del objeto: almacenada en el encabezado del objeto.

Modelo de estructura de objetos

3. Ajuste de herramientas de diagnóstico comunes de JVM

PD: El mecanismo de recolección de basura GC de JVM pertenece al subproceso del sistema. Antes de que se ejecute cada recolección de recursos, se ejecutará el método STW: "stop the world" para suspender todos los subprocesos del usuario.

Java VisualVM

Esta es la herramienta de visualización de caché que viene con jvm, puede ver:

• Parámetros de JVM, propiedades del sistema
• El uso de CPU, clase, montón y metaespacio del proceso
• Visual GC ve todo el uso de memoria del montón (es necesario instalar un complemento)

4. Hablando sobre el ajuste de JVM

Método de ajuste 1: evalúe el modelo de memoria del objeto del flujo de procesamiento del sistema central, determine el objeto de "Dawning Xishe" y ajuste el tamaño de la memoria del montón para el procesamiento.

Pregunta de la entrevista de Ali: ¿Puede sintonizar la JVM para que la GC completa casi no se produzca?
Escenario: Suponiendo que todo el objeto de la orden es de 60 megabytes, cuando el objeto de la orden sale del área eden y entra en el área S0, entrará directamente en la vejez porque excede el 50% de la memoria en el área S0.
Optimización: establezca el tamaño de la memoria de la vejez en 1G y el área del eden en 1.6G, S0 = 200m, S1 = 200m, en este momento, el objeto de pedido no ingresará a la vejez.