[Resolvido] System.gc()

Pessoal,

To desenvolvendo minha aplicação, blz, tenho varios frame todos funcionando perfeitamente, porém minha duvida é, quando instancio o frame ele ocupa X espaço na memoria, e quando fecho o frame este espaço não é liberado, fecho os frame pelo metodo this.dispose(), quando este software estiver em uso pelo cliente, que usará o dia todo, ele irá aliviar a memoria quando estiver em um nivel critico, ou devo setar todas as variveis como null antes de fechar a tela?
Alguem por favor poderia de dar uma explicacao, caso não tenha sido claro na minha duvida, é so post que eu tento explicar melhor

Tenha uma coisa em mente: mesmo chamando o System.gc(); não há garantia alguma de quando o garbage colector irá atuar.
Aliás, não é recomendado usar System.gc(). Esse comando não chama o garbage colector, apenas sugere para a jvm que talvez naquele momento seria bom pra atuar. Ficar fazendo essa sugestão pode fazer com que o GC rode desnecessariamente, causando considerável perda de desempenho.

Não é necessário setar null, desde que os objetos fiquem elegíveis para serem coletados, ou seja, não possuam referências a partir de objetos que estão no escopo, esses já serão coletados eventualmente. Novamente somente quando a jvm considerar necessário.

O que você pode fazer é analisar os lacks de memória com um profiler (procure pelo visual vm, vem com o java 1.6_u15 se não me engano) e garantir que esses objetos se tornem elegíveis para o GC. Também é válido a análise de uso excessivo e desnecessário de objetos, causando o grande consumo de memória descrito. Reveja seu algoritmo.

Resumo da ópera: use objetos com sabedoria e garanta que quando forem desnecessários esses sejam elegíveis pro GC. E deixe para a jvm o trabalho de administrar o GC.

[EDIT] Exatamente como Tchello citou.

Att.

Atenção: O dispose() não libera memória do Heap da VM. Ele apenas irá liberar os recursos do JFrame em relação ao sistema operacional, ou seja, a parte dele que fica “de fora” da VM.

Para que um JFrame seja coletado, além do dispose(), você precisa remover todas as referências a esse JFrame. Só assim o garbage collector poderá atuar sobre ele.

Oi,

Take a look:

http://www.guj.com.br/article.show.logic?id=28
http://javafree.uol.com.br/artigo/1386/Garbage-Collection.html -> Muito bom!

Tchauzin!

Obrigado pelas respostas, sobre a chamada ao gc eu já tinha o conhecimento que ele é uma sugestao para que rode, porém ainda tenho uma duvida, para remover todoas as referencias que tenho no frame, devo setar este como null, e todas as variaveis que aidna estiverem em execucao tambem serão nulas.
Bom tentando explicar melhor, tenho um JDialog, inicio ele desta forma

JDialog dialog = new JDialog(parent, true);
dialog.setVisible(true);

Como o dialog é modal ele não executa o resto do codigo enquanto não for fechado, então colequei a seguinte instrução logo abaixo do setVisible

dialog = null;

Seria esta a forma correta de desalocar este objeto.
Porém visualizando pelo gerenciador de tarefas do windows o meu aplicativo continua consumindo a mesma quantidade de memoria, o dialog já não esta mais na tela, porém a quantidade de memoria que o software usa é a mesma.

Agradeço pelas explicações já dadas.

Att,

Acho que você não sabe bem como funciona a alcação de memória em Java, sabe?

O java gerencia, ele mesmo, um heap. Esse heap, possui tanto memória para objetos já alocados, quanto para objetos ainda não alocados. Quando você faz uma alocação, é esse heap que você usa. E é o tamanho dele que você vê na VM.

Acontece que alocar e desalocar memória do SO é um processo caro. Por isso, o Java não desalocará espaço desse heap, imaginando que você irá utilizar aquela memória novamente em breve. A desalocação dessa memória só é feita se o espaço ficar por muito tempo ocioso.

Esse heap, é dividido em três partes. A dos objetos de vida curta, de vida longa e o lixo. O lixo, dentro do heap, é o que o garbage collector remove, mas ele não altera o tamanho do heap, e não há comandos para que o programador ordene essa redução.

Dê uma lida em:
A brief history of garbage collection. October 2003.
Garbage collection in the 1.4.1 JVM. November 2003.
Garbage collection and performance. January 2004.
Urban performance legends revisited: slow object allocation. September 2005.

Obrigado a todos que responderam a minha duvida.
ViniGodoy quanto a alocação de memoria, realmente não estudei muito, ou quase nada, porém agora estou desenvolvendo uma aplicação maior, vi que o consumo de memoria começa a ser percebivel, então veio a minha duvida, como eu deveria desalocar meus objetos de uma maneira correta.
Este conceito de gc estava meio confuso, pois eu observei o gerenciador de tarefa do S.O e o consumo de memoria não diminuia, mais não sabia, ou não me atentei, para o detalhe do heap de memoria.
Em resumo, o que entendi é que a memoria que visualizo no gerenciador de tarefas do S.O é a mesmoria consumida pelo heap, a qual só será desalocada em caso de um tempo ocioso muito grande, pois preseume-se que logo será utilizado novamente, então por o processo de desalocação e alocacao de memoria para o S.O ser caro, ele opta por só desalocar depois de um grande tempo ocioso.
Seria isto, caso esteja errado por favor me corrigião.
Obrigado novamente.

Pessoal, este link http://www.guj.com.br/posts/list/2340.java tambem me ajudou a entender melhor a ideia de desalocar objetos em java

Pessoal,

Obrigador a todas as resposta, duvida foi sanada, entendi o funcionamento do gargabe e que devo retirar as referencias de um objeto para que ele seja desalocado do heap, porém o tamanho do heap não irá diminuir imediatamente no S.O, devido ao custo de alocação e desalocação do S.O, utilizei o visual vm como citado pelo Tchello e percebi bem o funcionamento do heap.