Kdy pouzit Object.finalize()?

Čtvrtek Leden 28 19:16:59 CET 2010

Ad "po zavolani System.gc se vzdy spusti Full GC") S tim bych si dovolil 
polemizovat. V materiálech SCJP uvádí, že vynutit GC nelze, resp není to 
garantováno. Sice o to můžeme požádat právě voláním tohoto příkazu, ale 
GC se může rozhodnout, že nic neudělá. Záleží tak silně na implementaci 
JVM (jak to mají napsané).

Arny

Zdenek Tronicek wrote:
> Dost odstrasujici pripad.
>
> Volani System.gc() by mel kazdy vedouci projektu zakazat. Krome nekolika
> specialnich situaci, jako jsou performance testy, stejne k nicemu neni a
> velmi casto nadela vice skody nez uzitku (po zavolani System.gc se vzdy
> spusti Full GC a dochazi k presunu objektu z young generace do tenured).
>
> Z.T.
> --
> Zdenek Tronicek
> FIT CTU in Prague
>
>
> Oto Buchta napsal(a):
>   
>> K metodě finalize() - jediný smysl má tehdy, pokud si člověk sám řídí
>> Garbage collector. Vím minimálně o jednom případě, kdy jsem tak musel
>> činit, neb knihovna, kterou jsem musel použít, byla tak příšerně
>> napsaná, že to ani jinak nešlo. Z licenčních důvodů jsem do ní nemohl
>> zasáhnout a tak jsem jenom naimplementoval jednoduchý wrapper kolem
>> jejich dao objektu, který jsem zaregistroval pro použití místo jejich.
>> Po skončení určité části knihovna zavolala GC a to byla jediná chvíle,
>> kdy jsem se dostal k informaci, že je komunikace právě v tomto stavu.
>> K tomu samozřejmě mají vlastní GC a mluví o tom jako o úžasné
>> vlastnosti, že si sami prý qůli rychlosti řídí GC :-( No blivajz.
>>
>> Dne 28. ledna 2010 13:24 Filip Jirsák <filip.jirsak na gmail.com> napsal(a):
>>     
>>> Přesně tak jsem to myslel - ne vyhodit výjimku ať ji zpracuje někdo
>>> jiný,
>>> ale zpracovat ji stejným způsobem, jako výjimky obvykle zpracováváte, s
>>> přihlédnutím k tomu, že se pohybujete na tenkém ledě metody finalize().
>>>
>>> Filip Jirsák
>>>
>>>
>>> Dne 28. ledna 2010 12:50 Kamil Podlesak <kamil.podlesak na gmail.com>
>>> napsal(a):
>>>       
>>>> Tady bych opravil: výjimku ve finalize() zapsat do logu, vyhodit ji
>>>> nemá moc smysl (to je právě jeden z problémů finalize: co se stane
>>>> když vyletí výjimka?)
>>>>
>>>> Jinak tuto praktiku vřele doporučuji, samozřejmě je pak nutné nechat
>>>> nějak automaticky sledovat (grepovat) aplikační log na produkci a
>>>> nalezené chyby opravovat.
>>>> Spoléhat na programátorskou disciplinu je _velmi_ deprecated :-)
>>>>
>>>> Kamil Podlešák
>>>>
>>>> 2010/1/28 Filip Jirsák <filip.jirsak na gmail.com>:
>>>>         
>>>>> Ještě doplním, že může být vhodné tu pojistku doplnit assertem, který
>>>>> upozorní na to, že někdo někde tu úklidovou metodu zavolat zapomněl.
>>>>> Záleží
>>>>> pak na kontextu, jestli tohle stačí, nebo jestli je k tomu potřeba si
>>>>> táhnout nějakou další informaci - typicky v konstruktoru si (pod
>>>>> assertem)
>>>>> vytvořit výjimku, uložit si ji, při zavolání close() ji vymazat a ve
>>>>> finalize() otestovat její přítomnost, a pokud výjimka existuje,
>>>>>           
>>>> vyhodit
>>>>         
>>>>> jí.
>>>>>
>>>>> S pozdravem
>>>>>
>>>>> Filip Jirsák
>>>>>
>>>>> --
>>>>> filip na jirsak.org
>>>>>
>>>>>
>>>>> Dne 28. ledna 2010 11:44 Zdenek Tronicek <tronicek na fit.cvut.cz>
>>>>> napsal(a):
>>>>>           
>>>>>> Aplikacni programator udela nejlepe, kdyz na finalize() zapomene a
>>>>>> misto
>>>>>> nej bude pouzivat metodu pro uklid a try + finally:
>>>>>>
>>>>>> InputStream is = ...
>>>>>> try {
>>>>>>  ...
>>>>>> } finally {
>>>>>>  is.close();
>>>>>> }
>>>>>>
>>>>>> Pokud jde o to, zda ma finalize nekdy smysl, tak ano: muze to byt
>>>>>> pojistka
>>>>>> pro pripad, ze programator zapomnel zavolat uklidovou metodu.
>>>>>> Programator
>>>>>> by na to ovsem nemel spolehat a mel by se snazit, aby kazdy objekt
>>>>>>             
>>>> po
>>>>         
>>>>>> sobe
>>>>>> uklidil.
>>>>>> Jinak ten clanek, ktery uvadis, je z roku 98. Takze to asi nebude
>>>>>> nejvhodnejsi zdroj.
>>>>>>
>>>>>> Z.T.
>>>>>> --
>>>>>> Zdenek Tronicek
>>>>>> FIT CTU in Prague
>>>>>>
>>>>>>
>>>>>> Ondra Medek napsal(a):
>>>>>>             
>>>>>>> Ahoj,
>>>>>>>
>>>>>>> navazuji tak trochu na predchozi thread. Jsem ted zmaten, jesli ma
>>>>>>> Object.finalize() smysl nebo by mel byt @Deprecated. Pokud ma
>>>>>>>               
>>>> smysl,
>>>>         
>>>>>>> tak kdy ho pouzit?
>>>>>>>
>>>>>>> V JDK 1.6 JavaDoc dokumentaci
>>>>>>>
>>>>>>>
>>>>>>> http://java.sun.com/javase/6/docs/api/java/lang/Object.html#finalize%28%29
>>>>>>> stoji:
>>>>>>>
>>>>>>> "For example, the finalize method for an object that represents an
>>>>>>> input/output connection might perform explicit I/O transactions to
>>>>>>> break the connection before the object is permanently discarded."
>>>>>>>
>>>>>>> Clanek ja Javaworld
>>>>>>> http://www.javaworld.com/javaworld/jw-06-1998/jw-06-techniques.html
>>>>>>> tez radi ve finalize() uvolnovat systemove zdroje, ale pouze jako
>>>>>>> "fallback mechanism". (Coz mi presne sedi pro ten java.awt.Window
>>>>>>> problem).
>>>>>>>
>>>>>>> Progrepoval jsem JDK 1.6 zdrojaky a SUN se k finalize() asi stavi
>>>>>>> ambivalentne: nekde ho pouziva, nekde ne. Priklady pouziti:
>>>>>>> java.util.zip.ZipFile - zavira IO stream
>>>>>>> java.io.FileInputStream + java.io.FileOutputStream : zaviraji file
>>>>>>> descriptory
>>>>>>> ... a dalsi
>>>>>>>
>>>>>>> Nejvice je onen ambivalentni pristup videt na ImageInputStreamImpl
>>>>>>>               
>>>> a
>>>>         
>>>>>>> FileImageOutputStream z baliku javax.imageio.stream:
>>>>>>> ImageInputStreamImpl ma finalize(), ktere v podstate jen nastavi
>>>>>>> priznak isClosed = true
>>>>>>> FileImageOutputStream je potomek ImageInputStreamImpl a prepisuje
>>>>>>> finalize(), ve kterem nedela nic.
>>>>>>>
>>>>>>> Dale jsem nasel treba zakomentovany finalize(), ktery puvodne
>>>>>>> zavitral
>>>>>>> IO stream, v
>>>>>>>               
>>>> com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl
>>>>         
>>>>>>> s
>>>>>>> poznamkou, ze "It affects the performance greatly in multi-thread
>>>>>>> environment. ". Tedy ZipFile vesele IO stream zavira ve
>>>>>>>               
>>>> finalize(),
>>>>         
>>>>>>> kdezto CoreDocumentImpl  to ma zakomentovane.
>>>>>>>
>>>>>>> Diky
>>>>>>> Ondra Medek
>>>>>>>
>>>>>>>               
>>>>>           
>>>       
>>
>> --
>> Oto 'tapik' Buchta, tapik na buchtovi.cz, http://tapikuv.blogspot.com
>>
>>     
>
>
>   