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 <[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
