El código al que se hace referencia en este artículo proviene del código de muestra disponible en el blog de Oracle sobre Epsilon GC.

En este artículo, exploramos una opción particularmente intrigante en Java Garbage Collection (GC) conocida como Epsilon GC. Este algoritmo de recolección de basura destaca por su característica distintiva: no realiza ninguna recolección de basura. El recolector de basura (GC) Epsilon se incluyó en JDK 11.

Pero, ¿de qué sirve un recolector de basura si no está recolectando? (gorrón eh!!)

No, en realidad es bastante útil, uno de esos casos de uso proporcionados por el blog de Oracle, que he mejorado ligeramente para que sea más útil.

Para obtener más detalles, consulte la publicación del blog original:
https://blogs.oracle.com/javamagazine/post/epsilon-the-jdks-do-nothing-garbage-collector

El caso de uso: Epsilon GC es beneficioso para los desarrolladores que necesitan evaluar la asignación de memoria para un segmento particular de código sin la ayuda de una herramienta de creación de perfiles.

Desafío principal Los recolectores de basura tradicionales pueden oscurecer las métricas precisas de uso de memoria al borrar objetos continuamente. Esta interferencia dificulta determinar el consumo real de memoria de su código.

Epsilon GC aborda este problema actuando como no coleccionista. Si bien no es un algoritmo de recolección de basura en sí, sirve como una herramienta para comprender la asignación de memoria al abstenerse de realizar ninguna recolección de basura, lo que proporciona una imagen clara del uso de la memoria.

Nota: Es importante tener en cuenta que, dado que Epsilon GC no recupera memoria, una asignación excesiva puede provocar un OutOfMemoryError (OOM) en la JVM.

A continuación se muestra el código de muestra que se utilizará para demostrar la eficacia de Epsilon GC.:

public class EpsilonDemo {

    public static String formatSize(long v) {
        if (v 



Expectativa: 

El código asigna 80 MB de objetos de tipo byte. Deberíamos poder observar lo mismo con las declaraciones impresas cuando ejecutamos el código.

Ahora para ejecutar la versión compilada con/sin EpsilonGC:


Ejecutando con G1GC:



java -Xms100m -Xmx100m -XX: UseG1GC  EpsilonDemo
Starting allocations...
*** Free MEM = 102.2 MB
Completed successfully
*** Free MEM = 74.2 MB




Entonces, con G1GC vemos una imagen de asignación incorrecta de utilización de 28 MB


Ejecutando con EpsilonGC:



java -Xms100m -Xmx100m -XX: UnlockExperimentalVMOptions -XX: UseEpsilonGC EpsilonDemo
[0.004s][warning][gc,init] Consider enabling -XX: AlwaysPreTouch to avoid memory commit hiccups
Starting allocations...
*** Free MEM = 99.4 MB
Completed successfully
*** Free MEM = 18.7 MB 




Aquí puedes ver claramente la utilización de 80,7 MB

Espero que esto te ayude a ver cómo EpsilonGC puede ser muy útil para detectar patrones de uso de memoria en tu código. ¡Salud! ?