Garbage Collectors Algorithms
Garbage Collectors typically have the following goals (easier said than done)
- Muito curto “stop the world pauses” com um alvo de alguns milisegundos
- Pausa os tempos não aumentam com uma pilha, ao vivo, ou de raiz…tamanho do conjunto
- Para lidar com pilhas de tamanhos que variam de poucos MB até muitos TBs
- Alta concorrência – Todo o trabalho de levantamento pesado é feito enquanto os fios Java continuam a ser executados
- Alta capacidade de produção
- Fácil de afinar
Agregadores de lixo
Dados em pilha são divididos em múltiplas regiões de alocação (ou gerações) que são mantidas separadas com base na idade do objeto (i.e. o número de iterações de GC sobreviventes). Enquanto alguns coletores são uni-geracionais, os outros usam duas gerações: (1) a Geração Jovem (mais dividida em Eden e duas regiões Sobreviventes) e (2) a Geração Velha (ou Tenured).
Source: Blog de Ionut Balosin
Dois coletores geracionais:
Serial GC – O algoritmo usa um único fio para realizar todo o trabalho de coleta de lixo, o que o torna relativamente eficiente porque não há sobrecarga de comunicação entre os fios. É mais adequado para máquinas de processador único porque não pode tirar vantagem do hardware de multiprocessador.
Throughput (Paralelo) GC – Este algoritmo usa mark-copy na Geração Jovem e mark-sweep-compact na Geração Velha. Tanto as coleções Young como Old disparam eventos stop-the-world, parando todos os threads de aplicação para realizar a coleta de lixo. Ambos os coletores executam fases de marcação e cópia/compactação usando múltiplos threads, daí o nome ‘Parallel’.
Parallel Garbage Collector é adequado para máquinas multi-core nos casos em que seu objetivo principal é aumentar a produtividade. Maior rendimento é alcançado devido ao uso mais eficiente dos recursos do sistema:
- durante a coleta, todos os núcleos estão limpando o lixo em paralelo, resultando em pausas mais curtas
- entre ciclos de coleta de lixo nenhum dos coletores está consumindo quaisquer recursos
Garbage First (G1) GC – Este coletor é um coletor de lixo estilo servidor, direcionado para máquinas multi-processadoras com grandes memórias. Ele atende aos objetivos de coleta de lixo (GC) com alta probabilidade de pausa, enquanto alcança alto rendimento.
- O coletor G1 tem uma abordagem diferente em termos de modelo de memória heap. A pilha é dividida em um conjunto de regiões de pilha de tamanho igual, cada uma com uma gama contígua de memória virtual.
- A certos conjuntos de regiões são atribuídos os mesmos papéis (éden, sobrevivente, antigo) como nos coletores mais antigos, mas não há um tamanho fixo para eles.
- O tamanho da região é escolhido pela JVM na inicialização. A JVM geralmente tem como alvo cerca de 2000 regiões, variando em tamanho de 1 a 32Mb. O coletor G1 tem uma abordagem diferente
Para mais detalhes, consulte Getting Started with the G1 GC

Uni generational collectors:
Shenandoah GC – Shenandoah é o coletor de lixo de baixo tempo de pausa que reduz o tempo de pausa GC ao realizar mais trabalho de coleta de lixo simultaneamente com o programa Java em execução. Shenandoah faz a maior parte do trabalho de GC simultaneamente, incluindo a compactação concorrente, o que significa que seus tempos de pausa não são mais diretamente proporcionais ao tamanho da pilha de lixo. A coleta de lixo de uma pilha de 200 GB ou uma pilha de 2 GB deve ter um comportamento similar de baixa pausa.
Para mais detalhes, por favor consulte Detalhes de Implementação em Wiki
Z GC – ZGC é um coletor de compactação concorrente, de geração única, baseado na região, com consciência NUMA. As fases stop-the-world são limitadas ao scan de raiz, por isso os tempos de pausa do GC não aumentam com o tamanho do heap ou do live set.
Para mais detalhes, por favor consulte Session on ZGC by Per Liden no YouTube
Finally,
Epsilon GC (experimental)- Um GC que lida com alocação de memória mas não implementa nenhum mecanismo real de recuperação de memória. Uma vez esgotado o heap Java disponível, a JVM será desligada. Projetado para testes internos do JDK mas pode ser útil em duas situações
- Muitos programas de curta duração
- Programas são cuidadosamente escritos para reutilizar a memória e nunca realizam novas alocações