GC en serie
La recolección de elementos no utilizados mejora la eficiencia de la memoria en Java al eliminar los objetos sin referencia del montón y dejar espacio para los objetos recién creados.
La máquina virtual Java tiene ocho tipos de recolectores de basura. Consideremos cada uno de ellos en detalle.
Serial GC es la implementación de GC más simple. Está destinado a aplicaciones pequeñas que se ejecutan en entornos de subproceso único. Todos los eventos de recolección de basura se ejecutan secuencialmente en el mismo subproceso. La compactación se realiza después de cada recolección de basura.
La ejecución del recopilador da como resultado un evento de "parada mundial", donde se suspende toda la aplicación. Dado que toda la aplicación se congela durante la recolección de basura, no debe recurrir a esto en la vida real si desea mantener los retrasos lo más bajos posible.
El argumento de JVM para usar el recolector de basura en serie es -XX:+UseSerialGC .
GC paralelo
El recolector de basura paralelo está diseñado para aplicaciones con conjuntos de datos medianos a grandes que se ejecutan en hardware multiproceso o multiprocesador. Esta es la implementación predeterminada de GC y también se conoce como recopilador de rendimiento.
Varios subprocesos están destinados a la recolección de basura pequeña en la generación joven. El único subproceso está ocupado con la recolección de basura principal en la generación anterior.
Ejecutar un GC paralelo también hace que el mundo se "detenga" y la aplicación se cuelga. Este comportamiento es más apropiado para un entorno de subprocesos múltiples donde se deben completar muchas tareas y las pausas prolongadas son aceptables, como cuando se ejecuta un trabajo por lotes.
El argumento de JVM para usar el recolector de basura paralelo es -XX:+UseParallelGC .
GC de CMS
También lo conocemos como recogedor paralelo de descanso bajo .
Aquí, para una pequeña recolección de basura, varios hilos están involucrados, esto sucede a través del mismo algoritmo que en el recolector paralelo. La recolección de elementos no utilizados principal tiene múltiples subprocesos, al igual que el antiguo GC paralelo, pero el CMS se ejecuta simultáneamente con los procesos de la aplicación para minimizar los eventos de "parada mundial".
Debido a esto, el recopilador de CMS consume más CPU que otros recopiladores. Si tiene la capacidad de asignar más CPU para mejorar el rendimiento, entonces es preferible un CMS a un simple recopilador paralelo. El CMS GC no se compacta.
El argumento de JVM para usar el recolector de basura de barrido de marcas paralelo es -XX:+UseConcMarkSweepGC .
G1 (Basura primero) GC
G1GC se concibió como un reemplazo para CMS y se desarrolló para aplicaciones de subprocesos múltiples que se caracterizan por grandes tamaños de almacenamiento dinámico (superiores a 4 GB). Es paralelo y competitivo como un CMS, pero bajo el capó funciona de manera muy diferente a los antiguos recolectores de basura.
Aunque G1 también opera de forma generacional, no tiene espacios separados para las generaciones más jóvenes y mayores. En cambio, cada generación es un conjunto de regiones, lo que permite flexibilidad para cambiar el tamaño de la generación más joven.
G1 divide el montón en un conjunto de regiones de igual tamaño (según el tamaño del montón) y las analiza en varios subprocesos. El área durante la ejecución del programa puede volverse repetidamente tanto vieja como joven.
Una vez completada la fase de marcado, G1 sabe qué áreas contienen la mayor cantidad de basura. Si el usuario está interesado en minimizar las pausas, G1 solo puede seleccionar algunas áreas. Si el tiempo de pausa no es importante para el usuario, o si el límite de tiempo de pausa se establece en un valor alto, G1 repasará más áreas.
Dado que el GC G1 identifica las regiones con la mayor cantidad de basura y realiza la recolección de basura primero en esas regiones, se denomina "Garbage First".
Además de las áreas de Eden, Survivors y Old Memory, hay otros dos tipos en G1GC.
- Humongous (Enorme) - para objetos de gran tamaño (más del 50% del tamaño del montón).
- Disponible : espacio no utilizado o no asignado.
El argumento de JVM para usar el recolector de basura G1 es -XX:+UseG1GC .
Shenandoah (Shandara)
Shenandoah es un nuevo GC lanzado como parte de JDK 12. La ventaja clave de Shenandoah sobre G1 es que la mayor parte del ciclo de recolección de basura se realiza simultáneamente con los subprocesos de la aplicación. G1 solo puede evacuar áreas de montón cuando la aplicación está suspendida, mientras que Shenandoah mueve objetos al mismo tiempo que la aplicación.
Shenandoah puede compactar objetos vivos, limpiar basura y liberar RAM casi tan pronto como se encuentra memoria libre. Dado que todo esto sucede al mismo tiempo, sin suspender la aplicación, Shenandoah consume más CPU.
ZGC
ZGC es otro GC lanzado como parte de JDK 11 y mejorado en JDK 12.
Está destinado a aplicaciones que requieren velocidad y baja latencia (pausas de menos de 10 ms) y/o utilizan un montón muy grande (varios terabytes).
Los principales objetivos de ZGC son baja latencia, escalabilidad y facilidad de uso. Para ello, permite que la aplicación Java continúe ejecutándose a pesar de que las operaciones de recolección de basura estén en curso. De forma predeterminada, ZGC libera la memoria no utilizada y la devuelve al sistema operativo.
Por lo tanto, el ZGC brinda una mejora significativa con respecto a otros GC tradicionales al proporcionar tiempos muertos extremadamente bajos (generalmente dentro de los 2 ms).
El argumento de JVM para usar el recolector de basura ZGC es -XX:+UnlockExperimentalVMOptions -XX:+UseZGC .
GO TO FULL VERSION