Serão explicados também alguns pontos de ajuste na coleta de lixo, para obtenção de melhor performance. Ao final, falaremos sobre o G1, o novo coletor de lixo da JVM da Oracle (HotSpot).
Você já se perguntou o que acontece quando cria um objeto usando o operador new em seu código Java? O que se passa com o pequeno espaço de memória destinado ao objeto recém-criado quando o mesmo não é mais utilizado pela sua aplicação?
Quem já é mais antigo em programação e já trabalhou com linguagens como C ou C++ conhece bem o cuidado extra necessário na alocação e liberação de memória e os problemas resultantes desta complexidade, como é o caso dos memory leaks.
O fato é que em Java raramente nos preocupamos com este tipo de problema, porque a linguagem oferece o que chamamos de “coleta automática de lixo”.
Os Garbage Collectors, ou simplesmente GCs, estão presentes desde as primeiras versões do Java, realizando seu trabalho silencioso e na grande maioria das vezes eficiente, em muitos casos até mesmo sem serem percebidos.
Muitas vezes, principalmente quando estamos lidando com aplicações com grande quantidade de requisições, como uma aplicação web, para conseguir mais eficiência e performance precisamos entender melhor o funcionamento do mecanismo de GC, suas variações e seus ajustes.
Por ser a máquina virtual Java mais utilizada no mercado, neste artigo abordaremos as estratégias de GC da JVM HotSpot. Existem diversas flags para parametrizar o comportamento de coleta de lixo na JVM, mas ao invés de listarmos as flags e descrever seu uso, iremos destacar algumas delas pontualmente.
Ao final, apresentaremos o novo coletor G1, introduzido no Java 7u4. Este coletor é a aposta da Oracle para substituir os demais. Apesar de se tratar de um artigo específico à implementação da Oracle, os conceitos vistos aqui também podem ser aplicados quando o leitor estiver lidando com outras implementações de JVM.
Coleta de lixo
Em linguagens como C,era muito comum a gestão manual de memória. Toda vez que precisávamos alocar uma quantidade de memória dinamicamente, tínhamos que nos preocupar com a “devolução” dessa memória após o devido uso.
Listagem 1. Trecho de programa em C com alocação e liberação de memória.
int someFunction() {
int *obj = (int*) malloc(1000 * sizeof(int));
// trecho de código que faz algo com o espaço alocado apontado por obj
free(obj);
return 1;
}A Listagem 1 mostra a alocação de memória suficiente para armazenar uma lista de 1.000 inteiros e devolve a posição do primeiro espaço de memória para o ponteiro de inteiros obj. Desta forma, após o uso da memória o programador tinha que se preocupar com a sua liberação, através do comando free, por exemplo. O ponto é que o desenvolvedor tinha que fazer a gestão da memória manualmente e não eram raros os casos em que um malloc era chamado sem um free para a liberação correspondente, como ocorre na Listagem 2.
Listagem 2. Trecho de programa em C com problema de vazamento de memória.
int someOtherFunction() {
int *obj = (int*) malloc(1000 * sizeof(int));
// trecho de código que faz algo com o espaço alocado apontado por obj
// onde está o free?
return 1;
}Casoo trecho de código em questão fosse executado muitas vezes, cada vez mais memória sem uso continuaria sendo alocada. Este tipo de cenário, conhecido como “memory leak” (vazamento de memória), acabava por provocar o esgotamento de memória disponível para a aplicação e como consequência erros de falta ou invasão de memória eram comuns.
Observando este tipo de situação, criadores de linguagens modernas como o Java resolveram embarcar na linguagem (no caso do Java na JVM) estratégias para coleta automática de espaços de memória que não são mais referenciados pela aplicação, ou simplesmente, a col ...
