Os objetos são criados usando o novo, mas não há operação de exclusão correspondente para reciclar a memória ocupada pelo objeto. Quando concluímos o uso de um objeto, simplesmente paramos de nos referir a esse objeto: Altere nossa referência para apontar para outro objeto ou nulo; ou retornar do método para que as variáveis locais do método não existam mais, para que a referência a essas variáveis locais não aponte para nenhum objeto. Os objetos que não são mais referenciados são chamados de lixo. O processo de encontrar e reciclar esses objetos é chamado de coleta de lixo o
As máquinas virtuais Java usam a coleta de lixo para garantir que os objetos referenciados sejam retidos na memória e também liberarão o espaço de armazenamento ocupado por objetos inacessíveis por meio de qualquer referência no código de execução. Esta é uma forte garantia de que, se um objeto não for reciclado se a cadeia de referência que inicia a partir da referência raiz (ou seja, referências que podem ser acessadas diretamente no código de execução).
Em suma, quando não podemos alcançar um objeto de qualquer código executável, o espaço necessário pode ser reciclado. Observe que usamos a palavra "lata" porque se o espaço de memória é reciclado é determinado pelo coletor de lixo. Geralmente, o coletor de lixo só será executado se mais espaço de memória for necessário ou evitar o excesso de memória. No entanto, o programa pode sair sem transbordamento de memória, ou mesmo quando não está próximo do estouro de memória, portanto, pode não exigir coleta de lixo. Em todos os métodos atualmente executados, se todas as variáveis contiverem referências a um objeto e, começando dessas variáveis, as referências a esse objeto não podem ser encontradas em todos os domínios ou elementos de matriz ao longo da cadeia de referência, dizemos que o objeto é "inacessível".
A reciclagem de lixo significa que nunca precisamos nos preocupar com referências pendentes. Em sistemas em que os programadores podem controlar diretamente quando os objetos são excluídos, os programadores podem excluir objetos que outros objetos ainda estão referenciando. Se os programadores excluirem esses objetos, as referências que ainda estão referenciando objetos excluídos ficarão nulos porque se referem ao silêncio.
O sistema considera o espaço de memória alocável (mas na verdade o espaço foi lançado). O sistema pode alocar esse espaço alocável para novos objetos, para que as referências originalmente apontassem para o espaço realmente resultem em objetos completamente diferentes do que eles esperavam. Nesse caso, desastres imprevisíveis podem ocorrer quando o programa usa valores armazenados neste espaço e os opera como objetos aos quais não pertencem. A coleta de lixo resolve o problema de pendurar referências para nós, porque todos os objetos que ainda são referenciados não serão tratados como coleta de lixo; portanto, o espaço que eles ocupam não pode ser libertado. A coleta de lixo também resolve o problema de excluir acidentalmente o mesmo objeto várias vezes - esse problema também pode causar desastres. A reciclagem de objetos de lixo não requer nossa intervenção, mas a reciclagem de lixo ocupará uma certa quantidade de recursos do sistema. A criação e a reciclagem de um grande número de objetos podem interferir nos aplicativos críticos do tempo; portanto, ao projetar esses sistemas, devemos lidar cuidadosamente com o número de objetos criados para reduzir a quantidade de lixo a ser reciclada.
A coleta de lixo não garante que a memória sempre tenha espaço para criar novos objetos. Por exemplo, se continuarmos criando objetos e colocando -os em uma lista, não podemos mais criar novos objetos quando não houver espaço suficiente para criar novos objetos e não há objetos não referenciados. Se mantivermos as referências da lista acima para objetos que não são mais necessários, ocorrerá um vazamento de memória. A coleta de lixo resolve muitos (mas não todos) problemas de alocação de memória.
Interagir com o coletor de lixo
Embora a própria linguagem Java não tenha nenhuma maneira explícita de descartar objetos ociosos, ainda podemos encontrar objetos que não são mais usados chamando o coletor de lixo diretamente. Alguns métodos convenientes na aula de tempo de execução e no sistema permitem ligar para o coletor de lixo, solicitar que todos os finalizadores sejam executados ou visualize o status atual da memória:
.Public void gc q: Este método pede à máquina virtual Java para gastar objetos de reciclagem de energia que não são mais usados para que possa reutilizar a memória ocupada por esses objetos.
.Public void runfinalization (): Este método pede à máquina virtual Java para gastar energia executando os seguintes finalizadores: objetos que foram considerados inacessíveis, mas cujo finalizador ainda não foi executado.
"Public Long Freedom (): Retorna o número estimado de bytes disponíveis na memória do sistema.
Memory Public Long Total Long (): Retorna o número total de bytes na memória do sistema.
.Public Long MaxMemoryo: Retorna o número máximo de bytes de memória do sistema disponível para a máquina virtual Java. Se o sistema operacional não tiver restrições de uso de memória nas máquinas virtuais Java, por muito tempo. Valor máximo será devolvido. Não existe um método em Java para definir a memória máxima do sistema. Geralmente, as máquinas virtuais Java definem esse valor através da linha de comando ou outras opções de configuração.
Para chamar o método acima, precisamos obter uma referência ao objeto de tempo de execução atual através do método estático Runtime.GetRuntime. A classe do sistema suporta métodos estáticos de GC e runfinalização, que chamarão os métodos correspondentes no objeto Run-OMM atual; Em outras palavras, o System.GC () é equivalente a Runtime.GetRuntime (). GC () Métodos.
Ao chamar o método de execução de tempo de execução.gc (), o coletor de lixo não pode liberar nenhuma memória extra, porque pode não haver lixo a ser reciclado, e nem todos os coletores de lixo podem descobrir objetos recicláveis sob demanda. Portanto, chamar o coletor de lixo pode não ter nenhum efeito. No entanto, chamando o método RunTime.GC () é desejável antes de criar um grande número de objetos, especialmente em aplicações críticas de tempo, onde a sobrecarga de coleta de lixo pode afetá-lo. Existem dois benefícios potenciais em executá -lo: o primeiro é que podemos obter o máximo de memória possível antes de executar o aplicativo, e o segundo é que podemos reduzir a possibilidade de o coletor de lixo executar durante a execução de tarefas. O método a seguir libera ativamente todo o espaço que pode ser lançado em tempo de execução:
public static VO Recordful1GC () {RunTime RT = RunTime.getRuntime (); Long isFree = rt.freememory (); Long Wasfree; do {wasfree = isFree; rt.runfinalization (); rt.gc (); isFree dois rt.freememory (); } while (isfree> wasfree); }O método está constantemente em loop e o valor do freememory continua aumentando continuamente chamando os métodos Runfinalization e GC. Quando a quantidade de memória livre não aumenta mais, o loop do método termina.
Normalmente, não precisamos chamar o método Runfinalization, porque o método finalizado é chamado de forma assíncrona pelo coletor de lixo. Em alguns casos, por exemplo, quando um recurso que pode ser reciclado pelo método Finalize é esgotado, será útil aplicar o maior número possível de terminações, ligando para a finalização do Run. Mas lembre -se de que não podemos garantir que qualquer objeto que aguarde para ser encerrado esteja usando esse recurso, portanto, a runfinalização pode não ter nenhum efeito.
O método FullGC parece muito radical para a maioria das aplicações. Em casos especiais em que a coleta de lixo é necessária, mesmo que não todo o lixo disponível seja coletado por uma única chamada para o método System.GC, é a grande maioria dele. Portanto, chamadas repetidas reduzirão a taxa de saída da coleta de lixo e, em muitos sistemas, essas chamadas repetidas são sem saída.