Metodo System.gc();

Programação Java
#1

[i]Pessoal com o uso do metodo System.gc(); que elimina objetos não usadoos! Quanto a isso gostaria de saber!

  • isso traz ottimização ao codigooo?

  • quando é usado ?

  • á exemplo de algum codigo ?

  • Garbage Collector = " Coletor de Lixo Java ".

// ATT ();[/i]

#2

Não use System.gc()

O Garbage Collector funciona normalmente sem a interferencia dos desenvolvedores, se estive com algum problem é sua aplicação que está com um gargalo que deve ser tampado

[]'s

#3

Favor usar uma fonte normal de texto…

  1. Não traz otimização, aliás é melhor evitá-lo. A JVM que sabe a melhor hora de fazer coleta de lixo
  2. Um caso que conheço de uso é quando você quer apagar um arquivo, e a JVM fala que o arquivo ainda está em uso pelo sistema, mesmo que não esteja. Um jeito de contornar é usar o System.gc() antes do file.delete(). Melhor mesmo seria fazer isso numa nova tentativa de apagar o arquivo.
  3. Exemplo não tenho, é só usar.
#4

Realmente, como os colegas falaram, não traz otimização.

Repare também que a documentação do método diz que a VM não é obrigada a executar o garbage collector assim que o comando é chamado. Esse comando é só uma sugestão.

Esse comando é útil em algumas situações, geralmente muito específicas. Por exemplo, entre uma fase e outra de um jogo, ou antes de exibir um vídeo. Assim você reduz as chances de haver uma coleção de lixo longa no meio da sua tarefa principal. Para aplicações comerciais no geral, não vejo nenhum motivo para usa-lo.

#5

Onde eu encontro a documentação dos metodos?

OBG.

#6

Pode usar sim. Usando esse método você estará forçando a coleta de lixo. Em algumas aplicações, pode-se ganhar performance, se puder evitar o acumulo de objetos na memória. O gc pode demorar alguns segundos realizando trabalho em grandes coletas.

exemplo:

método que lê imagens de um stream de video e as filtra.

[code]
private doErosion(BufferedImage bi){

int width = 100;
int height = 100;

BufferedImage bimage = new BufferedImage(width, height, BufferedImage.TYPE_INT_RGB);
bimage = Filter.Erosion(bi);

bi = Filter.Clone(bimage);
bimage = null; //passando null para bimage, faz com que o coletor de lixo passe a enxerga-la. É útil também em aplicações que usam muitos String;
System.GC(); // realiza a coleta de lixo.
}[/code]

Agora não compensa usar, se, a sua aplicação não requer tempo crítico de processamento. É melhor a máquina virtual realizar automaticamente.

Esse link pode ser útil:

http://www.roseindia.net/javatutorials/determining_memory_usage_in_java.shtml

#7

Documentação:

http://java.sun.com/javase/6/docs/api/index.html?java/lang/System.html#gc()

#8

Só reiterando, você não está forçando, está apenas sugerindo. É muito raro a VM ignorar o comando (pelo menos a da sun).

#9

Só reiterando, você não está forçando, está apenas sugerindo. É muito raro a VM ignorar o comando (pelo menos a da sun). [/quote]
A vm pode ignorar o comando?

#10

É verdade. Não havia lido corretamente a documentação. Mas é meio estranho sugerir, não!? As vezes, nós precisamos.

#11

Só reiterando, você não está forçando, está apenas sugerindo. É muito raro a VM ignorar o comando (pelo menos a da sun). [/quote]
A vm pode ignorar o comando?[/quote]

Pode sim. Pelo menos é o que diz a documentação.
Nunca vi isso ocorrer.

Ah, fui dar uma olhada no artigo que você falou, mas ele me pareceu meio antigo (2001). Será que o que está lá ainda vale? O garbage collector é um dos códigos onde a sun dedica maior parte da sua atenção.

#12

Sim.

System.GC() não invoca o método que coleta o lixo, ele simplesmente sugere a JVM que aquela é uma boa hora para fazer essa coleta por que tem lixo a ser coletado e provavelmente mais pra frente isso pode ficar pesado.

Mas nada garante que será invocado.

#13

Como o ViniGodoy disse, não há nenhuma garantia. Ou mais especificamente, não há garantias que ela vá rodar na hora que foi chamada.

Ela pode ignorar o comando se há uns microsegundos atrás ela já fez o GC Full. Não tem por que rodar duas vezes seguidas.

#14

Estranhíssimo. Mas a sun nunca abriu mão do direito único e exclusivo que a VM tem de controlar o gc.
Já foram feitos pedidos para criar comandos que suspendam o gc, ou que forcem sua execução, mas implementações disso sempre foram negadas.

A próxima versão de garbage collector vai trazer modificações importantes, que a princípio o tornará apto a aplicações de tempo real. Mesmo nessa versão, será impossível forçar o gc a fazer qualquer coisa. Se quiser ler mais sobre ela:
http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5419&yr=2008&track=javase

#15

Me enganei, o link que você vai gostar de ver é esse aqui:
http://research.sun.com/jtech/pubs/04-g1-paper-ismm.pdf

#16

Estranhíssimo. Mas a sun nunca abriu mão do direito único e exclusivo que a VM tem de controlar o gc.
Já foram feitos pedidos para criar comandos que suspendam o gc, ou que forcem sua execução, mas implementações disso sempre foram negadas.

A próxima versão de garbage collector vai trazer modificações importantes, que a princípio o tornará apto a aplicações de tempo real. Mesmo nessa versão, será impossível forçar o gc a fazer qualquer coisa. Se quiser ler mais sobre ela:
http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5419&yr=2008&track=javase[/quote]

Tenho uma aplicação de vídeo, que captura de cameras ip. Isso lendo um mjpeg e criando sequencias jpg. Dado alguns minutos, o gc passava, e a captura parava por uns 10s. Passei a utilizar o System.GC(), e ele passou a realizar a coleta antes do acumulo. Fiz com base naquele artigo que postei. Até hoje não me trouxe mais problemas.

#17

Eu tive os mesmos problemas com jogos. Ao final de uma fase, geralmente todos os objetos do cenário são destruídos e um novo cenário é montado.
Então, o usuário começa a jogar a segunda fase e, bem no meio, o jogo congelava. Também resolvi chamando System.gc() logo após a troca de cenário.

#18

O G1, que é o novo gc, pelo que li, no link que o vini postou, é capaz de prever o tempo da pausa, e otimizar a coleta. Muito interessante. Vai resolver muitos problemas de performance.

#19

Mesmo com o g1, não é garantida a performance, como java realtime system.

#20

Sem que o programador controle exatamente o garbage collector, nunca será possível garantir hard-real time.
Pelo menos, não se o intervalo de tempo for muito curto.