O coletor de lixo é um processo de baixa prioridade executado periodicamente e libera memória usada por objetos que não são mais necessários. O coletor de lixo é executado em segundo plano, paralelamente ao programa, em um thread separado. A base para a coleta de lixo não é a contagem de referências, mas a separação dos objetos em dois tipos - alcançáveis e inacessíveis. Um objeto é considerado alcançável (vivo) se for referenciado por outro objeto alcançável (vivo). A acessibilidade é contada a partir de threads. Threads em execução são sempre considerados acessíveis (ativos), mesmo que ninguém faça referência a eles. Todos os objetos em Java são armazenados em uma área de memória especial chamada heap. Todos os objetos nos programas podem ser divididos em dois tipos - relativamente falando, objetos simples e objetos de “vida longa”. Objetos de “vida longa” são aqueles que sobreviveram a muitas coletas de lixo. Na maioria das vezes eles existirão até o final do programa. Como resultado, o heap comum, onde são armazenados todos os objetos criados, foi dividido em várias partes. A primeira parte tem um nome lindo - Éden (o “Jardim do Éden” bíblico), os objetos vão aqui depois de criados. É nesta parte que a memória é alocada para novos objetos quando escrevemos novos. Muitos objetos podem ser criados e, quando o espaço acabar nesta área, começa a primeira e “rápida” coleta de lixo. É preciso dizer que o coletor de lixo é muito inteligente e escolhe um algoritmo de trabalho dependendo do que há mais na pilha - lixo ou objetos de trabalho. Se quase todos os objetos forem lixo, o coletor marca os objetos “vivos” e os move para outra área de memória, após o que a área atual é completamente limpa. Se houver pouco lixo e a maior parte estiver ocupada por objetos vivos, ele marca o lixo, limpa e arruma os objetos restantes. A área de memória para onde são transferidos todos os objetos que sobrevivem a pelo menos uma coleta de lixo é chamada de Espaço de Sobrevivência. O Espaço de Sobrevivência, por sua vez, é dividido em gerações. Cada objeto recebe uma geração com base em quantas coletas de lixo ele sofreu. Se houver, pertence à “Geração 1”, se 5 – à “Geração 5”. Juntos, Eden e Survival Space formam uma área chamada Young Generation. Além da Young Generation, há outra área de memória na pilha - Old Generation (“velha geração”). Esses são os objetos de vida muito longa que sobreviveram a muitas coletas de lixo. É mais lucrativo armazená-los separadamente de todos os outros. E somente quando a área da Velha Geração estiver cheia, ou seja. Mesmo que haja tantos objetos de longa duração no programa que não haja memória suficiente, uma coleta de lixo completa é executada. Ele processa não apenas uma área de memória, mas geralmente todos os objetos criados pela máquina Java. Naturalmente, é preciso muito mais tempo e recursos. É por isso que foi decidido armazenar objetos de longa vida separadamente. Quando esgota o espaço em outras áreas, é realizada a chamada “coleta rápida de lixo”. Abrange apenas uma área e por isso é mais econômico e rápido. No final, Quando até a área dos moradores longevos já está congestionada, entra na briga a limpeza completa. Assim, a ferramenta mais “pesada” é utilizada pelo montador apenas quando não é mais necessária.
2. Que tipos de coletores de lixo existem?
Java possui sete tipos de coletores de lixo:
Coletor de lixo em série
Coletor de lixo paralelo
Coletor de lixo CMS
Coletor de Lixo G1
Coletor de Lixo Épsilon
Coletor de lixo Z
Coletor de lixo de Shenandoah
3. O que são “gerações” de objetos
Todos os objetos no Survival Space são divididos em gerações. Cada objeto recebe uma geração com base em quantas coletas de lixo ele sofreu. Se houver, pertence à “Geração 1”, se 5 – à “Geração 5”.
4. Para que é usado o SoftReference?
Um objeto referenciado apenas por referências suaves pode ser coletado como lixo se o programa ficar sem memória. Se um programa ficar sem memória repentinamente, antes de lançar uma OutOfMemoryException, o coletor de lixo excluirá todos os objetos referenciados por links virtuais e tentará alocar memória para o programa novamente. Um objeto que é impedido de morrer apenas pelo SoftReference pode sobreviver a qualquer número de coletas de lixo e provavelmente será destruído se o programa ficar sem memória.
5. Exemplo de uso de SoftReference
SoftReferences foram projetados especificamente para armazenamento em cache. Vamos supor que um programa cliente solicite frequentemente vários dados de um programa servidor. Em seguida, o programa servidor pode armazenar em cache alguns deles, usando SoftReference para isso. Se os objetos protegidos da morte por referências suaves ocuparem a maior parte da memória, o coletor de lixo simplesmente os excluirá e pronto.
6. Exemplo de uso de WeakReference
Se houver apenas referências fracas a um objeto, então esse objeto está ativo, mas será destruído durante a próxima coleta de lixo. Um objeto que é impedido de morrer apenas pelo WeakReference não sobreviverá à próxima coleta de lixo. Mas até que isso aconteça, você pode obtê-lo chamando um método get()em WeakReference e chamando seus métodos ou fazendo outra coisa. Um exemplo de uso de WeakReference é WeakHashMap.
7. Por que o WeakHashMap é necessário
WeakHashMap é um HashMap cujas chaves são referências fracas - WeakReference. Você armazena pares de objetos em um WeakHashMap – uma chave e um valor. Mas WeakHashMap não se refere diretamente às chaves, mas por meio de WeakReference. Portanto, quando os objetos usados como chaves se tornarem inacessíveis, eles serão destruídos durante a próxima coleta de lixo. Isso significa que seus valores serão removidos automaticamente do WeakHashMap. WeakHashMap é muito conveniente para armazenar informações adicionais para alguns objetos. Em primeiro lugar, é muito fácil de obter se você usar o próprio objeto como chave. Em segundo lugar, se um objeto for destruído, tanto ele quanto todos os dados associados a ele desaparecerão do HashMap. Por exemplo, o programa possui um thread que monitora o trabalho de alguns objetos de tarefa e grava informações sobre eles no log. Então este thread pode armazenar os objetos rastreados em um WeakHashMap. Assim que os objetos não forem mais necessários, o coletor de lixo irá excluí-los e as referências a eles do WeakHashMap serão automaticamente excluídas.
8. O que é um registrador
Um objeto Logger é usado para registrar mensagens para um sistema específico ou componente de aplicativo. Um log é uma lista de eventos que ocorreram. Na maioria das vezes, informações sobre os parâmetros do método com os quais ele foi chamado, todos os erros interceptados e muitas informações intermediárias são gravadas no log. Todo o processo de registro consiste em três partes.
A primeira parte é coletar informações.
A segunda parte é filtrar as informações coletadas.
A terceira parte é um registro das informações selecionadas.
9. Como configurar um registrador
Adicione dependência ao pom.xml.
Adicione o arquivo log4j.properties aos recursos.
Normalmente, as configurações do criador de logs log4j são definidas no arquivo log4j.properties. Neste arquivo você pode especificar vários anexadores - objetos nos quais os dados serão gravados.
Adicione à aula com lógica de negócios private static final Logger log = Logger.getLogger(ххх.class);.
GO TO FULL VERSION