Memory leak em Java

body { margin:20px; padding:0; } h1 { border-bottom:1px solid black; } form { margin-top:3em; font-size:85%; } fieldset { background:#ffc; margin:0 0 1em 0; border:1px solid #ddd; width:40em; } textarea { font-size:90%; } table#markuphint { float:right; background:#ffa; border:1px solid #ccc; font-size:90%; } table#markuphint tr { line-height:100%; } table#markuphint td { padding:0 7px; } pre#output { margin-left:3em; overflow:auto; } #parsed { border:1px solid #999; margin:0 2em 2em 3em; padding:1em; } #parsed td { border-style:solid; } #footer { border-top:1px solid black; }

Colaboração: Carlos Tosin (instrutor oficial dos Cursos On-Line de Java da Softblue)

Ao contrário do que muitas pessoas pensam, uma aplicação escrita em Java pode sim apresentar problemas de vazamento de memória, termo comumente conhecido por memory leak. Infelizmente, um grande número de programadores Java acha que memory leak é coisa de C/C++ e que o garbage collector do Java resolve esse problema completamente. Neste artigo pretendo mostrar que o garbage collector, apesar de ser funcionar muito bem, não é capaz de fazer mágica.

Memory leak significa exatamente o que o seu nome diz: vazamento de memória. Ele pode ser de dois tipos:

1) Blocos de memória: estão alocados e disponíveis para serem usados pela aplicação, mas não são acessíveis porque a aplicação não tem nenhum ponteiro* apontando para essa área de memória. Logo, estes blocos de memória não podem nem ser usados nem pela aplicação e nem por outros processos.

2) Blocos de memória: possuem dados que poderiam ser liberados por serem inacessíveis e que, por esquecimento, ainda são referenciados no código mesmo sem estarem sendo usados, não podendo ser liberados.

A situação 1 é muito comum em C/C++. Aloca-se uma quantidade de memória usando a função malloc*, por exemplo, e na seqüência o programador faz com que o ponteiro para essa área de memória passe a apontar para outro local, perdendo a referência inicial. Em Java este tipo de memory leak não ocorre, pois o garbage collector é capaz de detectar blocos de memória alocados e não referenciados e liberá-los para uso posterior.

É na situação 2 que mora o problema. Mas antes de explicar como esse problema pode ocorrer e como evitá-lo, vamos entender um pouco mais como funciona o garbage collector do Java.

*1 Um ponteiro é uma variável que aponta para um endereço de memória. É um termo bastante comum em C/C++ e engana-se quem acha que Java não possui ponteiros. Quando um objeto é criado usando new, a variável que recebe o objeto é, na verdade, um ponteiro que aponta para um endereço de memória que contém o objeto.

*2 A função malloc() faz parte da API do C. Sua função é alocar a quantidade de memória desejada (fornecida como parâmetro). O retorno desta função é um ponteiro para a área de memória recém criada.

O Papel do garbage collector

Uma das grandes vantagens do Java sobre linguagens de programação de mais baixo nível é a presença do garbage collector (coletor de lixo). A função do dele é vasculhar a memória atrás de blocos alocados que não tenham mais como ser referenciados pela aplicação. Quando o garbage collector se depara com uma situação desse tipo, ele desaloca a memória, tornando-a disponível para ser usada novamente pela aplicação.

Ver o garbage collector funcionando no Java é muito fácil. Observe este código:

public static void main(String[] args) throws Exception { int[] array = null; while(true) { array = new int[1000]; System.out.println("Bytes livres: "+ Runtime.getRuntime().freeMemory()); Thread.sleep(200); } }

Este código fica executando em um loop infinito. A cada iteração do loop, um array de 1000 posições de inteiros é criado. Cada vez que o loop é executado, é mostrada a quantidade de bytes livres. Num primeiro momento você pode pensar: esta aplicação vai acabar com a memória da JVM. Mas na verdade não é isso que acontece. Ao executar o programa, em determinado momento você vai observar a seguinte saída:

Bytes livres: 1530520 Bytes livres: 1530520 Bytes livres: 1530520 Bytes livres: 1526504 Bytes livres: 1522488 Bytes livres: 1518472 Bytes livres: 1514456 Bytes livres: 1510440 Bytes livres: 1912792 Bytes livres: 1912792 Bytes livres: 1908776 Bytes livres: 1904760 Bytes livres: 1900744 Bytes livres: 1896728 Bytes livres: 1892712

A memória estava acabando e, repentinamente, ela aumentou. A explicação disso é simples. Quando o loop é executado, é criado o array. Na próxima iteração do loop, o array criado na iteração anterior não é referenciado por mais ninguém (perceba que a variável array deixou de apontar para o array antigo e passou a apontar para o novo array, fazendo com que o array antigo ficasse inacessível). Em determinado momento, a JVM percebe a queda da memória disponível e coloca o garbage collector em execução. O garbage collector então descobre que essa memória que foi sendo alocada no decorrer dos loops está inacessível e a libera. É neste momento que podemos perceber que a memória disponível aumenta.

Depois de ver este código rodando, você deve estar se perguntando: como eu sei quando o garbage collector vai ser executado?. Não é possível saber. O controle da execução do garbage collector é da JVM. Quando a JVM decidir que é hora de executá-lo, ele será executado. Note que executar o garbage collector toda hora não seria recomendável, já que ele ocupa recursos computacionais.

Outro ponto importante a respeito do garbage collector é que, como ele é controlado pela JVM, não é possível forçar a sua execução via programação. O máximo que pode ser feito é a chamada do método System.gc() (ou Runtime.getRuntime().gc()). Este método notifica a JVM que a aplicação gostaria que o garbage collector fosse executado, mas não garante que ele realmente será executado no momento desejado.

O método finalize

A classe Object do Java possui um método chamado finalize(), que pode ser sobrescrito pelas classes que herdam de Object (isto é, qualquer classe). Quando o garbage collector decide que determinado objeto será destruído por não ser mais referenciado, ele chama o método finalize() no objeto logo antes de destruí-lo.

Apesar do método finalize() ser uma chance que o programador tem para liberar recursos associados ao objeto no momento em que ele será destruído, sobrescrever o finalize() não é recomendado em nenhuma situação. O motivo é simples: como não existe garantia que o objeto será destruído, também não existe garantia que o finalize() será executado. A própria Sun não recomenda sobrescrever o método finalize(). A liberação de recursos pode ser feita de outras formas, como utilização de blocos try/catch/finally e/ou criação de métodos específicos para este fim (método close(), por exemplo).

Para mais informações sobre este tópico, consulte: http://java.sun.com/developer/TechTips/2000/tt0124.html.

Causando um memory leak em Java

Após o entendimento do que é um memory leak e como funciona o garbage collector do Java, vamos agora mostrar como causar um memory leak em Java e o que fazer para evitá-lo. Primeiramente, gostaria de reforçar que memory leaks são difíceis de descobrir (às vezes é preciso recorrer a ferramentas externas) e sempre são causados por erro de programação. Normalmente os programadores não se preocupam muito com eles, até o momento em que começam a consumir uma quantidade excessiva de memória ou até derrubar a JVM (quando a memória acaba, a JVM lança um java.lang.OutOfMemoryError e termina).

Comentei na seção 3 que o garbage collector é capaz de detectar objetos não-referenciados e destruí-los, liberando a memória. Para criar um memory leak basta manter a referência a um ou mais objetos no código, mesmo sem utilizá-la depois. Dessa forma o garbage collector nunca poderá destruir os objetos, e eles continuarão existindo na memória mesmo não sendo mais acessíveis. Observe este exemplo simples de implementação de uma pilha:

public class Pilha { private List pilha = new ArrayList(); int count = 0; public void push(Object obj) { pilha.add(count++, obj); } public Object pop() { if(count == 0) { return null; } return pilha.get(--count); } }

Cada vez que um elemento é colocado ou removido da pilha, um contador controla a posição do último elemento. Este é um caso visível de memory leak. A pilha tem referências cadastradas para todos os objetos contidos nela. No entanto, por mais que os objetos sejam todos removidos da pilha, a pilha continuará referenciando os objetos removidos, o que impossibilitará o gargabe collector de recuperar esta memória.

Para resolver a situação nesse caso, basta eliminar a referência ao objeto quando ele for removido da pilha:

Atribuir a referência do objeto para null fará com que a pilha não mais referencie o objeto, possibilitando ao garbage collector a destruição do mesmo.

Este exemplo tem por objetivo mostrar como memory leak em Java é possível. É difícil alguém implementar uma pilha desta forma (ainda mais que Java já possui uma classe Stack para esta finalidade). De qualquer forma, imagine uma situação semelhante a essa onde milhares ou até milhões de objetos fiquem inacessíveis e ainda assim referenciados. Numa aplicação rodando sem parar num servidor de aplicação, por exemplo, isso pode acarretar o término da JVM por falta de memória após alguns dias de memory leaks acumulados. Numa situação como essa, encontrar o erro pode ser uma tarefa extremamente complicada e trabalhosa.

Recomendações para evitar memory leaks

Acredite: seguir algumas recomendações para evitar os memory leaks é muito mais fácil do que detectá-los após o código ter sido finalizado. Como o garbage collector facilita bastante o trabalho do programador, basta prestar atenção em alguns pontos principais que são causas comuns de memory leaks:

Cuidado com coleções de objetos (arrays, listas, maps, vectors, etc.). Às vezes elas podem guardar referências de objetos que não são mais necessários.

Ainda relacionado às coleções de objetos, se as mesmas forem static ou durarem todo o tempo de vida da aplicação, o cuidado deve ser redobrado.

Ao programar situações onde seja necessário registrar objetos como event listeners, tome o cuidado de remover os registros desses objetos caso não sejam mais necessários. Resumindo: elimine todas as referências a objetos desnecessários. Fazendo isso, o garbage collector terá condições de fazer o seu trabalho completamente e você estará livre dos memory leaks em suas aplicações.

Este artigo procurou demonstrar que memory leaks existem em Java, ao contrário do que muitas pessoas pensam. Foi mostrado como criar uma situação de memory leak e como cuidar para que situações desse tipo sejam evitadas, a fim de não prejudicarem as aplicações.

Carlos Tosin é instrutor oficial dos Cursos On-Line de Java da Softblue, formado em Ciência da Computação pela PUC-PR, pós-graduado em Desenvolvimento de Jogos para Computador pela Universidade Positivo e Mestre em Informática na área de Sistemas Distribuídos, também pela PUC-PR. Trabalha profissionalmente com Java há 7 anos e possui 4 anos de experiência no desenvolvimento de sistemas para a IBM dos Estados Unidos, utilizados a nível mundial. Atua há mais de 2 anos com cursos e treinamentos de profissionais em grandes empresas. Possui as certificações da Sun SCJP, SCJD, SCWCD, SCBCD, SCEA, IBM SOA e ITIL Foundation.

Autor: Carlos Eduardo Gusso Tosin

NetSaber - Artigos