Informatica
Garbage Collector (GC) é provavelmente o mecanismo mais mal entendido da plataforma Java. Em geral se pensa que o GC elimina toda a responsabilidade de gerência de memória do desenvolvedor de uma aplicação. Em outros casos ocorre o contrário, isto é, o desenvolvedor realiza muito mais trabalho do que é necessário.
Em Java, a alocação e desalocação de memória acontecem de maneira automática, controlada e transparente ao desenvolvedor, substituindo a utilização de ponteiros de memória por referências de objetos, evitando assim os vazamentos de memória e bugs de ponteiros. Desta forma, a linguagem Java é considerada mais segura neste aspecto. Em contrapartida, este gerenciamento automático de memória consome recursos computacionais quanto à decisão sobre a desalocação. Além disso, este processo é não-determinístico, ou seja, não há garantias sobre quando acontecerá a desalocação, se ela vier a acontecer. Antes de explicar mais detalhes sobre este processo, eis alguns conceitos iniciais: * Memória heap: espaço reservado pela JVM para a alocação de objetos em memória. Toda alocação de objeto em Java é realizada na memória heap. Da mesma forma, toda vez que um objeto é desalocado, a memória utilizada por este retorna como memória disponível para a heap; * Collection: processo automático de gerenciamento da memória heap, baseado em duas atividades: busca de objetos que não são mais acessíveis, e desalocação dos recursos utilizados por estes objetos; * Collector: algoritmo que realiza uma collection; * Throughput (vazão): porcentagem de tempo de execução não utilizada em collections, ou seja, teoricamente é o total de tempo de execução disponível para a aplicação, considerado sobre longos períodos de tempo; * Pausa: momento de tempo onde a aplicação fica não-responsiva porque uma collection está acontecendo.
O desempenho de uma aplicação está intimamente ligada ao custo da alocação e desalocação de memória. Se uma aplicação usa uma