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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]>: >>> > 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 >>> > >>> > -- >>> > [email protected] >>> > >>> > >>> > Dne 28. ledna 2010 11:44 Zdenek Tronicek <[email protected]> >>> > 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, [email protected], http://tapikuv.blogspot.com >
