Zdravím,
Efektivně by se měl považovat za deprecated.
Problém je v tom, že vlastně netušíme jaký je stav aplikace v
okamžiku volání finalize. Nevíme v jakém jsme právě vlákně, nevíme
jaké máme k dispozici prostředky. Může se docela klidně stát, že něco
co potřebujeme k "uklizení" je již uvolněno a finalizováno - nebo je
právě uvolňováno. Nevíme zda je bezpečné zamknout sdílené objekty nebo
není - čeká na nás GC nebo ne? A tak dále, a tak dále...
V jednoduchých případech nic z toho nevadí; bohužel, jednoduchých
případů moc není.
Jak jsem již napsal v předchozí diskusi: pokud potřebuji po nějakém
objektu "uklízet", místo finalize() je lepší používat PhantomReference
a uklízecího démona, který vybírá události o uvolnění objektu (z
ReferenceQueue) a pak provede úklid. Má to dvě hlavní výhody:
- uvolněný objekt již skutečně neexistuje - na rozdíl od finalize(),
kdy je v jakémsi nedefinovaném stavu ("očistec" ?)
- uklízecí démon může brát v úvahu aplikační stav - zda je již
aplikace plně inicializovaná a nakonfigurovaná, nebo naopak zda
probíhá shutdown, atd
- uklízecí démon má k dispozici všechno co celá aplikace - databáze,
komunikace s okolím, může klidně na všechno toto čekat...
Snad jsem to napsal trochu srozumitelně.
Kamil Podlešák
2010/1/28 Ondra Medek <[email protected]>:
> 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
>
