CodeGym /Cursos Java /Módulo 3 /Tipos de coletores de lixo em Java

Tipos de coletores de lixo em Java

Módulo 3
Nível 18 , Lição 5
Disponível

Serial GC

A coleta de lixo melhora a eficiência da memória em Java removendo objetos não referenciados da pilha e abrindo espaço para objetos recém-criados.

A máquina virtual Java possui oito tipos de coletores de lixo. Vamos considerar cada um deles em detalhes.

Serial GC é a implementação de GC mais simples. Destina-se a pequenos aplicativos executados em ambientes de thread único. Todos os eventos de coleta de lixo são executados sequencialmente no mesmo thread. A compactação é realizada após cada coleta de lixo.

Serial GC

A execução do coletor resulta em um evento "world stop", no qual todo o aplicativo é suspenso. Como todo o aplicativo é congelado durante a coleta de lixo, você não deve recorrer a isso na vida real se quiser manter os atrasos o mais baixo possível.

O argumento JVM para usar o coletor de lixo serial é -XX:+UseSerialGC .

GC Paralelo

O coletor de lixo paralelo foi projetado para aplicativos com conjuntos de dados médios a grandes executados em hardware multiencadeado ou multiprocessador. Essa é a implementação padrão do GC e também é conhecida como coletor de throughput.

Vários segmentos são destinados a pequenas coletas de lixo na geração jovem. O único thread está ocupado com a coleta de lixo principal na geração mais antiga.

GC Paralelo

A execução de um GC paralelo também faz com que o mundo “pare” e o aplicativo trave. Esse comportamento é mais apropriado para um ambiente multiencadeado em que muitas tarefas precisam ser concluídas e longas pausas são aceitáveis, como ao executar uma tarefa em lote.

O argumento da JVM para usar o coletor de lixo paralelo é -XX:+UseParallelGC .

CMS GC

Também conhecido por nós como o selecionador paralelo de descanso baixo .

Aqui, para uma pequena coleta de lixo, vários threads estão envolvidos, isso acontece por meio do mesmo algoritmo do coletor paralelo. A coleta de lixo principal é multiencadeada, assim como o antigo GC paralelo, mas o CMS é executado simultaneamente com os processos do aplicativo para minimizar os eventos de "parada mundial".

CMS GC

Por causa disso, o coletor CMS consome mais CPU do que outros coletores. Se você tiver a capacidade de alocar mais CPU para melhorar o desempenho, um CMS é preferível a um coletor paralelo simples. O CMS GC não compacta.

O argumento JVM para usar o coletor de lixo de varredura de marcação paralelo é -XX:+UseConcMarkSweepGC .

G1 (Lixo primeiro) GC

O G1GC foi concebido como um substituto para o CMS e foi desenvolvido para aplicativos multi-threaded caracterizados por grandes tamanhos de heap (maiores que 4 GB). É paralelo e competitivo como um CMS, mas sob o capô funciona de maneira muito diferente dos antigos coletores de lixo.

Embora o G1 também funcione de forma geracional, não possui espaços separados para as gerações mais novas e mais velhas. Em vez disso, cada geração é um conjunto de regiões, permitindo flexibilidade na alteração do tamanho da geração mais jovem.

G1 divide o heap em um conjunto de regiões de tamanho igual (dependendo do tamanho do heap) e as verifica em vários threads. A área durante a execução do programa pode tornar-se repetidamente velha e jovem.

Após a conclusão da fase de marcação, o G1 sabe quais áreas contêm mais lixo. Se o usuário estiver interessado em minimizar as pausas, o G1 poderá selecionar apenas algumas áreas. Se o tempo de pausa não for importante para o usuário, ou se o limite de tempo de pausa for alto, o G1 percorrerá mais áreas.

Como o G1 GC identifica as regiões com mais lixo e realiza a coleta de lixo nessas regiões primeiro, ele é chamado de "Garbage First".

Além das áreas de Eden, Survivors e Old Memory, existem dois outros tipos no G1GC.

  • Enorme (enorme) - para objetos de tamanho grande (mais de 50% do tamanho da pilha).
  • Disponível - Espaço não utilizado ou não alocado.

O argumento da JVM para usar o coletor de lixo G1 é -XX:+UseG1GC .

Shenandoah (Shandara)

O Shenandoah é um novo GC lançado como parte do JDK 12. A principal vantagem do Shenandoah sobre o G1 é que a maior parte do ciclo de coleta de lixo é feita simultaneamente com os encadeamentos do aplicativo. G1 só pode evacuar áreas de pilha quando o aplicativo está suspenso, enquanto Shenandoah move objetos ao mesmo tempo que o aplicativo.

Shenandoah pode compactar objetos vivos, limpar o lixo e liberar RAM quase tão logo a memória livre seja encontrada. Como tudo isso acontece ao mesmo tempo, sem suspender o aplicativo, o Shenandoah consome mais CPU.

Argumento da JVM para o coletor de lixo Shenandoah: -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC .

ZGC

ZGC é outro GC lançado como parte do JDK 11 e aprimorado no JDK 12.

Destina-se a aplicações que requerem velocidade e baixa latência (pausas inferiores a 10 ms) e/ou utilizam um heap muito grande (vários terabytes).

Os principais objetivos do ZGC são baixa latência, escalabilidade e facilidade de uso. Para fazer isso, ele permite que o aplicativo Java continue em execução, apesar do fato de que as operações de coleta de lixo estão em andamento. Por padrão, o ZGC libera a memória não utilizada e a devolve ao sistema operacional.

Assim, o ZGC traz uma melhoria significativa em relação a outros GCs tradicionais, fornecendo tempos mortos extremamente baixos (normalmente dentro de 2ms).

Principais objetivos do ZGC 

O argumento JVM para usar o coletor de lixo ZGC é -XX:+UnlockExperimentalVMOptions -XX:+UseZGC .

Comentários
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION