Ricardo Munhoz Santiago wrote:
>
> � o seguinte,
>
> N�o existe garantia do momento em que o Garbage Colector ir� executar a
> coleta de lixo, mas em determinado momento isso acontecer�. Neste caso, se
> nehuma chamada expl�cita tiver sido feita ao metodo protect void finalize ()
> throws Throwable, o sistema o invocar� para voc�.
>
> Moral da est�ria, n�o se preocupe com quando o lixo da memoria ser�
> coletado, ele ser� coletado no momento mais apropriado para a VM.
> Se voc� est� alocando recursos (n�o memoria) que voce quer liberar quando
> seu objeto for destruido, simplesmente sobrescreva o methodo
> finalize, N�O SE ESQUE�A de incluir uma chamada ao finalize da super classe
> da qual voce derivou a sua classe.
>
Um comentario. O finalize pode levar um tempo consideravel para ser
chamado, e se voce esperar para liberar seus recursos so nesse
momento, pode ser que voce passe muito tempo prendendo recursos
importantes.
Isso pode ser uma preocupacao em objetos que utilizam
recursos como conexoes a banco de dados, ou conexoes de rede, e
que muitas vezes permanecem no sistema por muito mais tempo
do que o tempo no qual a conexao sera necessaria. Uma outra razao
para a demora do finalize (isso nao ocorre no HotSpot) eh que
o GC da JVM "classica" eh dito "conservador" e podem ser necessarias
varias passagens do GC antes que seu objeto seja efetivamente
marcado para ser GC'ed.
Uma tecnica eh ter um metodo do tipo "freeResources()" que
voce chama quando considerar apropriado (algumas pessoas gostam
de chamar esse metodo de "destroy", uma lembranca do C++, mas
eu acho que nesse caso "destroy" nao passa a ideia correta...)
public void freeResources() {
if (!recursos_foram_liberados) {
//libera recursos
}
}
public void finalize() {
super.finalize();
freeResources();
// libera outros recursos quaisquer
}
Outra coisa importante, para agilizar o trabalho do GC, libere
explicitamente suas referencias o mais rapido possivel (basta
iguala-las a null):
ResourceHungryObject rho = new ResourceHungryObject();
...
// use o rho pelo tempo que for necessario
...
rho.freeResources();
rho = null;
O problema com esse processo eh que voce pode estar liberando os
recursos de rho muito cedo. Isso acontecera se por exemplo voce
tiver passado rho para algum outro objeto, e esse outro objeto ainda
estiver utilizando rho no momento que voce chamou freeResources.
Esse eh o problema evitado com o uso do finalize (esse eh o motivo
dele existir).
Para contornar isso (lembre-se, estamos considerando que voce tem
recursos que sejam importantes, e que voce quer libera-los o mais
cedo possivel), voce devera verificar se o recurso esta disponivel
antes de utiliza-lo, e tentar readiquiri-lo se nao estiver.
Finalmente, se o seu recurso for realmente escasso, e for caro ou
dificil de criar, voce deve considerar algum processo de cache ou
pool de objetos.
Como ultimo comentario, tenha certeza que o recurso que voce esta
tendo que liberar seja importante de ser liberado rapidamente,
pois os comentarios que coloquei aqui _podem_ criar mais problemas
do que solucoes se nao forem utilizados corretamente.
Abracos,
Bruno.
> Uma dica, nunca invoque diretamente o metodo finalize.
>
> Se voc� quiser pedir � VM para que execute o garbage coletor, invoque
> System.gc (). Quando este metodo retornar, a VM ter� feito seu MELHOR
> ESFOR�O para executar o garbage colector, contudo, isso n�o � uma garantia.
>
> Ricardo Munhoz Santiago
>
> -----Mensagem original-----
> De: Narilton <[EMAIL PROTECTED]>
> Para: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Data: Ter�a-feira, 6 de Julho de 1999 13:24
> Assunto: evento destrutor
>
> >Ola Pessoal...
> >
> >Estava estudando Java, e fiquei com uma duvida, qndo que realmente acontece
> >o evento destrutor, e qndo que ocorre o momento do coletor de dados, que
> >limpa a area de memoria^{
> >
> >
> >narilton
> >
> >
> >
> >* Para nao receber mais e-mails da lista, acesse
> <http://www.sun.com.br:8080/guest/RemoteAvailableLists>, coloque seu e-mail,
> escolha a lista <[EMAIL PROTECTED]> e de um <submit>.
>
> * Para nao receber mais e-mails da lista, acesse
><http://www.sun.com.br:8080/guest/RemoteAvailableLists>, coloque seu e-mail, escolha
>a lista <[EMAIL PROTECTED]> e de um <submit>.
--
Bruno.
______________________________________________________________________
Bruno Peres Ferreira de Souza Sun Microsystems
System Engineer - Java Technologist [EMAIL PROTECTED]
if I fail, if I succeed, at least I live as I believe
* Para nao receber mais e-mails da lista, acesse
<http://www.sun.com.br:8080/guest/RemoteAvailableLists>, coloque seu e-mail, escolha a
lista <[EMAIL PROTECTED]> e de um <submit>.
