O código mencionado neste artigo é proveniente de código de amostra disponível no blog da Oracle sobre Epsilon GC.

Neste artigo, exploramos uma opção particularmente intrigante em Java Garbage Collection (GC) conhecida como Epsilon GC. Este algoritmo de coleta de lixo é notável por sua característica distintiva: ele não realiza coleta de lixo. O coletor de lixo Epsilon (GC) foi incluído no JDK 11.

Mas de que adianta um coletor de lixo se ele não coleta? (aproveitador hein!!)

Não, na verdade é bastante útil, um caso de uso fornecido pelo blog da Oracle, que melhorei ligeiramente para ser mais útil.

Para mais detalhes, consulte a postagem original do blog:
https://blogs.oracle.com/javamagazine/post/epsilon-the-jdks-do-nothing-garbage-collector

O caso de uso: Epsilon GC é benéfico para desenvolvedores que precisam avaliar a alocação de memória para um determinado segmento de código sem a ajuda de uma ferramenta de criação de perfil.

Desafio principal Os coletores de lixo tradicionais podem ocultar métricas precisas de uso de memória limpando objetos continuamente. Essa interferência torna difícil determinar o verdadeiro consumo de memória do seu código.

Epsilon GC resolve esse problema agindo como um não colecionador. Embora não seja um algoritmo de coleta de lixo em si, ele serve como uma ferramenta para entender a alocação de memória, evitando realizar qualquer coleta de lixo, fornecendo assim uma imagem clara do uso da memória.

Nota: É importante estar ciente de que, como o Epsilon GC não recupera memória, a alocação excessiva pode levar a um OutOfMemoryError (OOM) na JVM.

Abaixo está o código de exemplo que será utilizado para demonstrar a eficácia do Epsilon GC.:

public class EpsilonDemo {

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



Expectativa: 

O código aloca 80 MB de objetos do tipo byte. Devemos ser capazes de observar o mesmo com as instruções de impressão quando executamos o código.

Agora, para executar a versão compilada com/sem EpsilonGC:

Executando com G1GC:

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




Portanto, com G1GC, vemos uma imagem de alocação incorreta de utilização de 28 MB

Executando com 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 




Aqui você pode ver claramente a utilização de 80,7 MB

Espero que isso ajude você a ver como o EpsilonGC pode ser muito útil para detectar padrões de uso de memória em seu código. Saúde! ?