Java Efetivo Essencial - Referência Obsoleta
Tags: java, backend, memoryleak, javaefetivo
Published: 2022-08-12 20:24:00

## Elimine referências obsoletas de objetos

_Esta é uma série baseada no entendimento de tópicos relacionados ao livro com foco no resumo._

**Deu Ruim**

 Em algum momento o desenvolvedor Java já ouviu falar ou já se deparou com um problema de Memory Leak, se não ainda, algum dia talvez.
Mas talvez isso soe estranho já que temos o GC(Garbage Collector) no Java, muitos desenvolvedores podem pensar que se preocupar com o gerenciamento de memória pertence apenas a outras linguagens que não possuem esse recurso.

**O que é Memory Leak?**

Resumidamente é um vazamento de memória, geralmente causada quando há objetos presentes no heap que não estão sendo mais usados, mas o GC não consegue removê-los da memória e eles ficam ocupando espaço desnecessariamente.
Esses vazamentos em muitos casos são silenciosos e causam falhas no sistema como o incrível "OutofMemoryError". E esse tipo de situação deveria ocorrer raramente.

**O que é Garbage Collector?**

Um dos grandes trunfos da plataforma Java é o GC. Simplóriamente definindo,  o Garbage Collector procura na memória partes alocadas que não tenham mais como ser referenciados pela aplicação. Dessa forma, é desalocada a informação da memória, liberando espaço para ser usado pela aplicação.

**Referências Obsoletas**

 O livro da um exemplo de uma classe que faz manipulação de um vetor. É criada uma estrutura de dados simulando uma pilha de Objetos. Existem três métodos, sendo que o método adicionarNaPilha() é responsável por adicionar na pilha de dados um novo objeto e o método pegarDaPilha() retira da pilha de dados o objeto.
 O problema de vazamento de memória esta no método pegarDaPilha(), pois ele altera a variável tamanho sem remover de fato a referência do objeto que foi solicitado.

**Exemplo com Vazamento de memória**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lqwewhtxc1nciamdtv9q.png)

**O que isso significa?**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pk04zdp2wpp8r8uuzc31.png)

**Correção**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/94dz7khzrfdxryit86bm.png)

O código acima irá fazer com que de fato a referência do objeto seja removida do vetor e então o objeto esteja eleito para remoção do GC. Porém tomem cuidado, muitos devs quando aprendem isso querem colocar null em tudo ! Essa é a exceção não a regra.
A melhor forma é deixar a variável que contém a referência fora de escopo, ou seja, crie ela em um escopo limitado. 

**Outras fontes de vazamento de Memória**

Uma outra forma que o livro cita de possível vazamento de memória é adicionar referências de objetos em cache, uso de listeners e funções de callback.
Para cache o ideal é termos limpeza do cache com recorrência para que os objetos sejam removidos e liberados da memória.
No caso de callbacks é orientado o uso de referências fracas e para isso ele aconselha armazenamento como chaves em um WeakHashMap.
Mas além dessas temos muitas outras situações que não são citadas no livro que podem gerar vazamento de memória.

**Como dectectar?**

A maioria de ferramentas de APM e monitoria hoje em dia permitem analisarmos métricas do GC, da memória e da JVM.
Ferramentas como DataDog, New Relic, etc...
Porém o livro cita o uso de uma ferramenta especifica para Memory Leak que é o Heap Profiler.