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.
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.
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".
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.
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).
O argumento JVM para usar o coletor de lixo ZGC é -XX:+UnlockExperimentalVMOptions -XX:+UseZGC .