Estructura de memoria JVM y modelo de memoria JMM

Modelo de memoria de JAVA: montón, pila, área de método en JVM (el área de método es la definición conceptual de la especificación de JVM, en la máquina virtual HotSpot, la realización del área de método en HotSpot es una generación permanente y la realización del área de método en la versión 1.8 es metaespacio, el metaespacio se implementa usando memoria nativa, es decir, su memoria no está en la máquina virtual, y teóricamente limitada por la memoria de la máquina física), el contador de programa, etc.son la estructura de memoria del virtual Java Después de iniciar el programa Java, estos datos de memoria se inicializarán. Como se muestra abajo

El modelo de memoria es otra cosa. ¿Qué es el modelo de memoria?

En las computadoras, la CPU y la memoria interactúan con mayor frecuencia. En comparación con la memoria, las lecturas y escrituras de disco son demasiado lentas y la memoria equivale a un búfer de alta velocidad, pero la velocidad de lectura y escritura de la memoria está muy por detrás de la de la CPU, por lo que los fabricantes de CPU agregue un búfer de alta velocidad a cada cpu, se usa para aliviar esta situación, la interacción entre cpu y memoria es aproximadamente cpu <=> caché (generalmente L1, L2, L3) <=> memoria, el caché resuelve la contradicción entre el procesador y la memoria (uno rápido y otro lento), pero también trae el problema de la consistencia de la caché. En una CPU de varios núcleos, cada núcleo tiene su propia caché de alta velocidad y solo hay una memoria principal (cuando la CPU quiere leer un dato, primero busca en la memoria principal L1-L2-L3- , y cada CPU tiene un solo conjunto (Caché propio) ¿Cómo garantizar que cuando múltiples operaciones de procesador involucran la misma área de memoria, habrá problemas de consistencia de caché en escenarios de subprocesos múltiples, por lo que la consistencia de datos está garantizada en tiempo de ejecución? Garantizado por la CPU, cada procesador debe seguir la garantía del protocolo de coherencia (como MSI, MESI).

Barrera de memoria:

La caché de alta velocidad en la CPU mejora el rendimiento del acceso a los datos y evita solicitar de la memoria cada vez, pero no puede intercambiar información con la memoria en tiempo real. Los diferentes subprocesos ejecutados por varias CPU tienen diferentes valores de caché para la misma variable . Confíe en la barrera de memoria para asegurarse de que la barrera de memoria de la capa de hardware se divida en dos tipos: barrera de carga (barrera de lectura), barrera de almacenamiento (barrera de escritura). La barrera de la memoria está a nivel de hardware. Debido a que diferentes hardware implementan barreras de memoria de diferentes maneras, Java protege estas diferencias y genera instrucciones de barrera de memoria a través de jvm. Para barreras de memoria de lectura: inserte una barrera de lectura antes de la instrucción para invalidar los datos en la caché y forzar el acceso desde la memoria principal.

La función de la barrera de memoria: 1. Evita la reorganización de las instrucciones en ambos lados de la barrera 2. Forza el búfer de escritura y los datos sucios en la caché para que se vuelvan a escribir en la memoria principal para invalidar los datos correspondientes en la caché. (La palabra clave volátil utiliza una barrera de memoria. Cuando se escribe una variable modificada volátil, se generará una instrucción de ensamblaje especial. Esta instrucción activará el protocolo mesi. Habrá un mecanismo de rastreo de bus. En pocas palabras, esto La CPU estará constantemente detectar el cambio de la variable en el bus. Si la variable se cambia una vez, debido a este mecanismo de rastreo, otros cpus borrarán inmediatamente los datos de la caché de la cpu de la variable y obtendrán los datos de la memoria principal nuevamente)

Área de memoria JAVA

Todo lo anterior se basa en la máquina virtual HotSpot. La configuración del modelo de memoria Java se ajusta a las especificaciones mencionadas anteriormente en la computadora. La asignación de memoria del programa Java se completa bajo el mecanismo de asignación de memoria de la máquina virtual JVM. El modelo de memoria Java (JMM) es un tipo de modelo de memoria que se ajusta a las especificaciones del modelo de memoria, protege las diferencias de acceso de varios hardware y sistemas operativos y garantiza que los programas Java puedan acceder a la memoria en varias plataformas para garantizar resultados consistentes. El mecanismo y la especificación de En resumen, JMM es una especificación de JVM, que define el modelo de memoria de JVM. Protege las diferencias de acceso de varios hardware y sistemas operativos. No es directamente accesible a la memoria de hardware como c. Es relativamente más seguro. Su objetivo principal es resolver la inconsistencia y la compilación de datos de memoria local debido a la comunicación multiproceso a través de El procesador reordenará las instrucciones del código y el procesador ejecutará el código fuera de orden. Puede garantizar la atomicidad, la visibilidad y el orden en escenarios de programación concurrentes.

El área de datos de JAVA se divide en cinco áreas de datos: montón, pila de métodos locales, pila de máquinas virtuales, contador de programas, área de métodos

Contador de programa:

El contador del programa es un pequeño espacio de memoria, que se utiliza principalmente para registrar la dirección del bytecode ejecutado por cada hilo. Por ejemplo, ramas, bucles, saltos, excepciones, recuperación de hilos, etc., todos dependen del contador. Dado que Java es un lenguaje de subprocesos múltiples, cuando el número de subprocesos ejecutados excede el número de núcleos de CPU, los subprocesos sondearán los recursos de la CPU en función de los intervalos de tiempo. Si se agota el intervalo de tiempo de un subproceso, u otras razones hacen que los recursos de la CPU de este subproceso se apropien, entonces el subproceso que sale necesita un contador de programa separado para registrar la siguiente instrucción en ejecución. Si encuentra un método nativo (método nativo), este método no es ejecutado específicamente por la JVM, por lo que no es necesario registrar el contador de programa. Esto se debe a que también hay un contador de programa en el nivel del sistema operativo, que registrará la dirección de ejecución del código local, por lo que cuando se ejecuta el método nativo, el valor del contador del programa en la JVM no está definido. Además, el contador de programa es también la única área de memoria en la JVM que no OOM (OutOfMemory).

Pila de máquinas virtuales JAVA:

Estructura de datos: estructura de datos FILO

Rol: Almacene los datos, las instrucciones y las direcciones de retorno requeridas por el método de ejecución del hilo actual durante el proceso de ejecución de JVM.

Basado en subprocesos: se ejecuta de manera subprocesada. En el ciclo de vida de un subproceso, los datos involucrados en el cálculo se empujarán con frecuencia dentro y fuera de la pila, y el ciclo de vida de la pila es el mismo que el de un subproceso. El tamaño predeterminado de la pila de la máquina virtual es 1M, que se puede ajustar con el parámetro -Xss, por ejemplo -Xss256k.

El hilo es privado y la pila describe el modelo de memoria de la ejecución del método java. Cuando se ejecuta cada método, se crea un marco de pila para almacenar la tabla de variables locales, la pila de operaciones, el enlace dinámico, la salida del método y otra información. El proceso en el que se llama a cada método corresponde al proceso de un marco de pila desde el empuje hasta la aparición en la pila de la máquina virtual.

Stack frame: estructura de datos utilizada para almacenar datos y resultados parciales del proceso.
La ubicación del marco de la pila: memoria -> área de datos en tiempo de ejecución -> un hilo corresponde a la pila de la máquina virtual -> marco de la pila
El tamaño y el tiempo de determinación del marco de la pila: determinado durante la compilación y no afectado por los datos en ejecución

La pila generalmente se refiere a la parte de la tabla de variables locales. La tabla de variables locales es un espacio de memoria continuo que almacena parámetros del método, variables locales definidas en el método, tipos de datos conocidos durante la compilación (ocho tipos básicos y tipos de referencia) y direcciones de retorno.

Cabe señalar que el espacio de memoria requerido por la tabla de variables locales se asigna en el momento de la compilación. Al ingresar un método, la cantidad de espacio de variables locales que este método necesita asignar en la pila se determina completamente y la variable local no se modificará durante la ejecución del método Tamaño de tabla variable. Dos tipos de excepciones que pueden aparecer en la pila de la máquina virtual Java:

StackOverflowError: esta excepción se lanzará si la profundidad de la pila solicitada por el hilo es mayor que la profundidad de la pila permitida por la máquina virtual
OutOfMemoryError: el espacio de pila de la máquina virtual se puede expandir dinámicamente. Esta excepción se lanzará cuando la expansión dinámica no pueda solicitar suficiente espacio

Pila de métodos locales:

La función de la pila de métodos locales es similar a la de la pila de máquinas virtuales Java. La pila de máquinas virtuales Java se utiliza para gestionar las llamadas de funciones Java, y la pila de métodos locales se utiliza para gestionar las llamadas de métodos locales. Pero el método nativo no está implementado en Java, sino en lenguaje C (como el método Object.hashcode). La pila de métodos nativos es un área muy similar a la pila de máquinas virtuales, y los objetos a los que sirve son métodos nativos. Incluso puede pensar en la pila de la máquina virtual y la pila del método local como la misma área. No hay ningún requisito obligatorio en la especificación de la máquina virtual. Cada versión de la máquina virtual se puede implementar libremente. HotSpot combina directamente la pila de métodos locales y la pila de máquinas virtuales en una.

montón:

El montón es el área de memoria más grande de la JVM. Casi todos los objetos que solicitamos se almacenan aquí. En la recolección de basura solemos decir, el objeto de operación es el montón. El espacio de pila generalmente se solicita cuando se inicia el programa, pero no se utilizará todo. El montón generalmente está configurado para ser escalable. Con la creación frecuente de objetos, cada vez se ocupa más espacio en la pila y los objetos que ya no se utilizan deben reciclarse de vez en cuando. Esto se llama GC (recolección de basura) en Java. Cuando se crea ese objeto, ¿se asigna en el montón o en la pila? Esto está relacionado con dos aspectos: el tipo de objeto y la ubicación en la clase Java. Los objetos Java se pueden dividir en tipos de datos básicos y objetos ordinarios. Para objetos ordinarios, la JVM primero creará el objeto en el montón y luego usará su referencia en otro lugar. Por ejemplo, guarde esta referencia en la tabla de variables locales de la pila de la máquina virtual. Para los tipos de datos básicos (byte, short, int, long, float, double, char), hay dos casos. Cuando declaras un objeto de tipo de datos básico en el cuerpo del método, se asignará directamente a la pila. En otros casos, se asigna en el montón.

Parámetros de tamaño de
pila : -Xms: el valor mínimo de la pila;
-Xmx: el valor máximo de la pila;
-Xmn: el tamaño de la nueva generación;
-XX: NewSize; el valor mínimo de la nueva generación;
-XX: MaxNewSize: el valor máximo de la nueva generación;
por ejemplo, Xmx256m

Área de método:

El área de método, como el montón, es un área de memoria compartida por todos los subprocesos. Para distinguir el montón, también se llama non-heap. Se utiliza para almacenar información de clase, constantes y variables estáticas que ha cargado la máquina virtual. Por ejemplo, las variables estáticas modificadas se cargan en el área de método cuando se carga la clase.

El grupo de constantes de tiempo de ejecución es parte del área de métodos Además de la información de descripción de los campos, interfaces y métodos de la clase, el archivo de clase también tiene un grupo de constantes para almacenar varias referencias literales y simbólicas generadas durante la compilación. En la versión antigua de jdk, el área de método también se llama generación permanente, porque no hay un requisito obligatorio de que el área de método deba ser recolectada de basura. La máquina virtual HotSpot implementa el área de método con generación permanente. El recolector de basura de la JVM puede administrar esta área como el área del montón. Por lo tanto, no es necesario diseñar específicamente un mecanismo de recolección de basura para esta parte. Desde JDK7, la máquina virtual Hotspot ha eliminado el grupo de constantes de tiempo de ejecución de la generación permanente. jdk8 realmente comenzó a abandonar la generación permanente y a usar el metaespacio. La máquina virtual Java está relativamente suelta en el área de métodos. Además del montón, no hay espacio de memoria continuo, espacio definido y espacio expandible, y también puede elegir no para implementar la recolección de basura.

¿Por qué Java8 usa el metaespacio en lugar de la generación permanente y cuáles son los beneficios de hacerlo?
La explicación oficial es: la eliminación de la generación permanente es un esfuerzo para integrar HotSpot JVM y JRockit VM, ya que JRockit no tiene una generación permanente, no es necesario configurar una generación permanente. La memoria de generación permanente a menudo es insuficiente o se produce un desbordamiento de la memoria, lo que genera la excepción java.lang.OutOfMemoryError: PermGen (generación permanente). Esto se debe a que en la versión JDK1.7, el tamaño del área de PermGen especificada es 8 M. Dado que la información de metadatos de las clases en PermGen se puede recopilar en cada FullGC, la tasa de recuperación es baja y los resultados son difíciles de satisfacer; También es difícil determinar cuánto espacio asignar para PermGen El tamaño de PermSize depende de muchos factores, como el número total de clases cargadas por la JVM, el tamaño del grupo constante y el tamaño del método.

Análisis de grupo constante JDK1.8:

Grupo de constantes de clase: hora de nacimiento: tiempo de compilación; ubicación: montón (el grupo de constantes de clase se almacena en el archivo de clase, un archivo de clase corresponde a un grupo de constantes); contenido de almacenamiento: referencias simbólicas y literales
Grupo de constantes de cadena: tiempo de nacimiento: tiempo de compilación; ubicación: montón; contenido de almacenamiento: referencias y constantes de cadena de objetos de cadena en el montón
Grupo de constantes de tiempo de ejecución: hora de nacimiento: cuando la clase se carga en la memoria; área: memoria local (los datos del grupo de constantes después de que se cargue cada clase se resumen en el grupo de constantes de tiempo de ejecución y el grupo de constantes de tiempo de ejecución se almacena en el metaespacio) ; Contenido de almacenamiento: descripción de metainformación del archivo de clase, datos de código compilados, datos de tipo de referencia (después de analizar la clase, las referencias de símbolos se reemplazarán con referencias directas. El proceso de análisis consultará el grupo de constantes de cadena para garantizar el grupo de constantes de tiempo de ejecución. la cadena entre comillas es coherente con la cadena entre comillas en el grupo de cadenas global).

Memoria directa (memoria sin pila):

La memoria directa tiene un nombre más científico, memoria fuera de la pila. Cuando la JVM se está ejecutando, solicitará un gran bloque de memoria de pila del sistema operativo para almacenar datos; también hay pilas de máquinas virtuales, pilas de métodos locales y contadores de programas, que se denominan áreas de pila. La memoria restante del sistema operativo es la memoria fuera del montón. No es parte del área de datos en tiempo de ejecución de la máquina virtual, ni es el área de memoria definida en la especificación de la máquina virtual Java; si se usa NIO, esta área se usará con frecuencia, y los objetos directByteBuffer pueden hacer referencia a ella y manipularla directamente en el montón de Java; esta memoria de bloque no está limitada por el tamaño del montón de Java, pero está limitada por la memoria total de la máquina, que se puede configurar por -XX: MaxDirectMemorySize (el valor predeterminado es el mismo que la memoria de montón máxima), por lo que También pueden producirse excepciones OOM.

El diseño de memoria del objeto:

En HotSpot, el diseño de almacenamiento de memoria de los objetos se divide en: 1. Encabezado del objeto; 2. Datos de muestra; 3. Alineación y relleno

//TODO

Introducción a gc

GC (Garbage Collection): La recolección de basura se utiliza principalmente para recuperar y liberar el espacio ocupado por la basura. JAVA GC generalmente se refiere a la recolección de basura de Java.

¿Qué áreas de basura deben reciclarse? ¿Cuándo se reciclará? ¿Cómo reciclar?

¿Qué memoria necesita ser recuperada? Se han entendido las cinco áreas principales en el modelo de memoria de Java. El contador de programa, la pila de la máquina virtual y la pila del método local nacen de subprocesos y mueren con subprocesos. Los marcos de la pila en la pila se insertan en la pila cuando el método ingresa al Al igual que con las operaciones emergentes, la cantidad de memoria que necesita asignar un marco de pila depende de la implementación específica de la máquina virtual y se determina durante la compilación [Ignore la optimización realizada por el compilador JIT, que básicamente se conoce durante la compilación], cuando el método o se ejecuta el hilo, la memoria se recuperará, por lo que no hay necesidad de preocuparse. El área del método y el montón de Java son diferentes. El área de método almacena la información de carga de la clase, pero la memoria requerida por múltiples clases de implementación en una interfaz puede ser diferente, y la memoria requerida por múltiples ramas en un método también puede ser diferente [solo durante el tiempo de ejecución puede saber qué métodos este método crea El objeto no necesita mucha memoria], la asignación y recuperación de esta parte de la memoria son dinámicas, y gc también se ocupa de esta parte de la memoria.

¿El área de recuperación del montón?

Young Generation (Young Generation) NewSize y MaxNewSize pueden controlar el tamaño inicial y el tamaño máximo de la generación joven respectivamente
Vieja generación
Generación permanente [Usando metaespacio después de 1.8, no estará en el montón]

¿Algoritmo para determinar si el objeto está vivo?

1. El algoritmo de recuento de referencias
utilizó este algoritmo para juzgar si el objeto estaba vivo en los primeros días. Este juicio de algoritmo es muy simple. En pocas palabras, es agregar un contador de referencia al objeto. Cuando se hace referencia al objeto, aumenta en 1, y la referencia no será válida. Menos 1. Cuando es 0, se considera que no se volverá a hacer referencia al objeto.
Ventajas: Implementación simple y alta eficiencia, ampliamente utilizado en lenguajes de programación de juegos como Python.
Desventajas: Es difícil resolver el problema de las referencias circulares, es decir, si dos objetos se refieren entre sí y ya no serán referenciados por otros otros objetos, no se podrá reciclar si no siempre es 0.

2. Algoritmo de análisis de accesibilidad Los
lenguajes comerciales dominantes actuales [como java, c #] utilizan el algoritmo de análisis de accesibilidad para determinar si el objeto está vivo. Este algoritmo resuelve eficazmente los inconvenientes del reciclaje. Su idea básica es utilizar un objeto llamado "GC Roots" como punto de partida, y la ruta de búsqueda se llama cadena de referencia.Cuando un objeto se conecta a GC Roots sin ninguna referencia a él, se demuestra que el objeto es inutilizable. Hay cuatro tipos de objetos como GC Roots

El objeto al que se hace referencia en la pila de la máquina virtual (tabla de variables locales en el marco de la pila).
El objeto al que hacen referencia las propiedades estáticas de la clase en el área de método generalmente se refiere al objeto al que hace referencia la modificación estática y se carga en la memoria cuando se carga la clase.
El objeto al que hace referencia la constante en el área de método,
Objetos referenciados por JNI (método nativo) en la pila de métodos nativos

Algoritmo de recolección de basura

Marcar / borrar algoritmo [básico]
Copiar algoritmo
Algoritmo de marcado / organización

JVM utiliza un "algoritmo de recopilación generacional" para utilizar diferentes algoritmos de recuperación para diferentes áreas.

El Cenozoico adopta un algoritmo de replicación : En el Cenozoico, los objetos "viven y mueren", con una tasa de muerte del 98%, lo que es adecuado para el algoritmo de replicación [el algoritmo de replicación es más adecuado para áreas de memoria con bajas tasas de supervivencia]. Optimiza la eficiencia del algoritmo de marcado / barrido y el problema de la fragmentación de la memoria, y la JVM no asigna memoria a 5: 5 [Debido a la baja tasa de supervivencia, no hay necesidad de copiar y reservar un área tan grande, que causa un desperdicio de espacio, por lo que no es necesario presionar 1: 1 [Área original: espacio reservado] para dividir el área de memoria, sino dividir la memoria en un pedazo de espacio Edén y De sobreviviente, a sobreviviente [espacio reservado], el La proporción predeterminada de los tres es 8: 1: 1, el área Edén se usa primero, si Edén Cuando el área está llena, copie el objeto en la segunda área de memoria. Sin embargo, no hay garantía de que no haya más del 10% del inventario de objetos para cada colección, por lo que si el área de Superviviente no es suficiente, dependerá del inventario de vejez para su asignación]. El proceso de reciclaje de la nueva generación es: [To Survivor] se mantiene vacío antes de GC, y los objetos se almacenan en Eden y [From Survivor]. Cuando GC se está ejecutando, los objetos supervivientes en Eden se copian en [To Survivor]. Para los objetos supervivientes en [De superviviente], se considerará la edad del objeto. Si la edad no alcanza el umbral (umbral de tenencia, por defecto 15), el objeto se copiará a [Para superviviente]. Si se alcanza el umbral, el objeto se copia a la generación anterior. Una vez finalizada la fase de copia, solo los objetos muertos se guardan en Eden y [From Survivor], que pueden considerarse vacíos. Si se completa [To Survivor] durante el proceso de copia, los objetos restantes se copiarán a la generación anterior. Finalmente, [From Survivor] y [To Survivor] cambiarán los nombres. En el próximo CG, [To Survivor] se convertirá en [From Survivor].

La vejez adopta [Mark Clear] y [Mark Sort], dado que la vejez tiene una alta tasa de supervivencia y no hay espacio extra que lo garantice, se deben utilizar estos dos algoritmos.

Recolector de basura:

Si el algoritmo de recolección de basura es la metodología de recuperación de memoria, entonces el recolector de basura es la implementación específica. JVM utilizará diferentes recopiladores en combinación con diferentes escenarios y configuraciones de usuario.

Coleccionistas de generaciones jóvenes: Serial, ParNew, Parallel Scavenge
Coleccionista de vejez: Serial Old, Parallel Old, CMS
Coleccionista especial: coleccionista G1 (no en la categoría de jóvenes y mayores)

Colector cenozoico:

Serial: el recopilador más básico y más desarrollado. Antes de jdk3, era la única opción para los recopiladores de gc. Serial es un recopilador de un solo subproceso. Solo se puede usar un subproceso para la recopilación. Los demás subprocesos deben detenerse durante la recopilación. Espere a el trabajo de recopilación debe completarse antes de que otros subprocesos puedan continuar funcionando.

ParNew: versión mejorada en serie, admite subprocesos múltiples (subproceso GC), cuando funciona, es lo mismo que Serial Stop the word, el primer recopilador de simultaneidad real de HotSpot, la cantidad de subprocesos habilitados por defecto es la misma que la cantidad de CPU ( nueva generación en modo servidor) El recopilador es la primera opción, porque solo él y el Serial se pueden usar con CMS en la nueva generación de recopiladores)

Eliminación paralela: adopta un algoritmo de replicación, admite subprocesos múltiples y se centra en el rendimiento (rendimiento = tiempo de ejecución del código / (tiempo de ejecución del código + tiempo de recolección de basura)). Por ejemplo, si el código se ejecuta durante 99 minutos y la recolección de basura es 1 minuto, rendimiento = 99%. Adecuado para escenas con tiempo de pausa corto

Coleccionista de vieja generación:

Serial Old: Single-thread, la versión anterior de Serial, pero usa el algoritmo de organización de marcas y también requiere STW

Parallel Old: Admite múltiples subprocesos, apareció la versión anterior de Parallel Scavenge, apareció jdk1.6, algoritmo de clasificación de marcas, los recolectores de edad avanzada usan principalmente este algoritmo

CMS: (Concurrent Mark Sweep) es un recopilador que tiene como objetivo obtener el tiempo de pausa de recuperación más corto (énfasis en la respuesta, llamado recolector de pausa baja concurrente por Sun), algoritmo de barrido de marcas y admite la concurrencia. El proceso de reciclaje es el siguiente

Marca inicial: marca los objetos con los que GC Roots puede asociarse directamente, marca de un solo hilo, velocidad rápida, STW
Marcado concurrente: proceso GC Roots Tarcing, análisis de accesibilidad
Remarcado: Para corregir el registro de marcado de la parte del objeto que se cambia debido al funcionamiento del programa de usuario durante el marcado concurrente, habrá una pequeña pausa. Generalmente, el marcado inicial en el tiempo <Remarcado marcado <Marcado concurrente, STW
Limpieza concurrente

Problema de gran volumen de CMS:

La fragmentación de la memoria es grave. Una vez que ocurre mucha fragmentación en la generación anterior y los objetos de la generación joven no pueden encontrar espacio, usarán Serial Old para marcar y organizar
La basura flotante no se puede procesar. La basura flotante es basura nueva generada cuando CMS recolecta basura. En este momento, CMS no puede procesar esta basura y necesita ser procesada la próxima vez.

Recolector G1: (primero recolecta la basura la mayor cantidad de basura posible para evitar Full GC), uno de los recolectores más avanzados, después de 1.7, se enfoca en la baja latencia, reemplaza la función cms y resuelve una serie de problemas como la fragmentación del espacio causado por cms. (Extracto de Oracle: recolector de basura generacional estilo servidor de pausa baja para Java HotSpot VM. G1 GC utiliza etapas simultáneas y paralelas para lograr su tiempo de pausa objetivo y mantener un buen rendimiento. Cuando G1 GC determina que es necesario Durante la recolección de basura, Primero recolectará el área con menos datos de supervivencia (basura primero). La característica especial de g1 es que fortalece la partición y debilita el concepto de generación. Es un recolector regionalizado e incremental, que no es un nuevo nacimiento. Generación no pertenece al recopilador de la vieja generación. El algoritmo utilizado es el algoritmo de copia y limpieza de marcas)

JDK1.7-1.8 está deshabilitado de forma predeterminada y la opción de habilitación es -XX: + UseG1GC

g1 está regionalizado, divide la memoria del montón de Java en varias regiones del mismo tamaño [región], jvm puede establecer el tamaño de cada región (1-32m, el tamaño depende del tamaño de la memoria del montón, debe ser una potencia de 2) , Asignará un tamaño de región razonable según la memoria de pila actual. g1 busca objetos supervivientes en la generación anterior a través de la fase de marcado concurrente (paralelo) y comprime los objetos supervivientes mediante la replicación paralela [esto ahorra espacio continuo para objetos grandes]. g1 copia los objetos supervivientes en uno o más grupos de áreas en diferentes áreas de forma incremental y paralela para la compresión, reduciendo así la fragmentación del montón. El objetivo es recuperar la mayor cantidad de espacio del montón posible [basura primero], y en la medida de lo posible no exceder el objetivo de suspensión Para lograr el propósito de baja latencia. g1 proporciona tres modos de recolección de basura: gc joven, gc mixto y gc completo. A diferencia de otros recolectores, puede recolectar objetos de la nueva generación y la generación anterior según la región en lugar de la generación.

Minor GC: la recolección de basura en la generación joven (incluyendo el área de Eden y Suriver) se llama Minor GC, y solo se limpia la generación joven

GC principal: limpieza de la generación anterior (GC anterior), pero también puede denominarse equivalente a GC completo, porque la recopilación de la generación anterior suele ir acompañada de la actualización de la generación joven y la recopilación de todo el montón de Java.

GC completo: es una colección unificada de la nueva generación, la vieja generación, la generación permanente [jdk1.7] y el metaespacio [jdk1.8].

GC mixto: específico para G1, GC mixto, recolectando el gen joven completo y parte del GC del gen antiguo. Solo G1 tiene este modo