Kedy dojde k odstraneniu objektu?

[Robert Novotny]

Ano, ja som si uz na seminari uvedomil, ze to nie je dobre riesenie
(ani ako demonstracia) a teda, ze jedine dobre riesenie je
manualne zatvorenie. V tom danom priklade, ktory sme
na seminari rozoberali, by to vsak ulohu skomplikovalo.

Moralne ponaucenie z toho je, ze ak sa v niecom nevyznate dobre,
a chcete si tym zjednodusit situaciu, tak to radsej nepouzivajte,
lebo z toho vzidu este ovela vacsie hrozy.

On Thu, 26 Feb 2009 15:48:17 +0100, Ondrej Nekola <ondra na nekola.cz> wrote:

> Na neco takoveho vam finalize nepomuze. Duvody psalo nekolik lidi prede  
> mnou.
> O finalize se podrobneji pise trebas v Blochovi. Vysledek je, ze  
> moznosti pro jeho pouziti jsou male, nekdo tu ukazoval "zalozni"  
> dealokaci nekritickych zdroju, ja bych doplnil moznost napsat nejaky  
> vypis typu "Tady nejaky pitomec programator neuzavrel spojeni, trida XYZ  
> neni spravne uzivana."
> finalize() bych radeji nikdy nevolal manualne, napsal bych si radeji  
> metodu close() nebo finishWork() nebo dealocate().. popsal ji v javadocu  
> a tu volal rucne. A pak (po overeni, ze je to treba) ji pripadne volal z  
> finalize jako moznost posledni zachrany.
> 	OSN
> PS: mnohdy je finaly to, co potrebujete.
>
>> Presne toto som vcera pozoroval na seminari z Javy.
>> Mali sme priklad, ked trieda mala po ukonceni aplikacie serializovat  
>> svoje data
>> na disk.
>>
>> Najzjavnejsi a najjednoduchsi napad bolo pouzit finalize(). V  
>> inteligentnejsich pripadoch
>> by sa totiz zadanie skomplikovalo a na to nebol cas.
>>
>> Polovici ludi to zbehlo a druhej polovici nie.
>> Aby sme to nakoniec nekomplikovali, rozhodli
>> sme sa volat finalize() manualne. Viac som po tom nepatral.
>>
>> Ked sa na to pozeram, opat sa ukazalo, ze finalize() by v podstate
>> malo byt zakazane, lebo posobi len neplechu.
>>
>> Vdaka za vysvetlenie.
>>
>> RN
>>
>>
>>
>> On Wed, 25 Feb 2009 10:44:41 +0100, Lukáš Zapletal  
>> <lukas na zapletalovi.com> wrote:
>>
>>> Necetl jsem to vse cele, ale je nutne si uvedomovat, ze GC nemusi
>>> objekt uklidit vubec! Paklize dojde k ukonceni programu, nez dojde
>>> pridelena heap a GC se "nerozhodne" vubec pro uklid, tak se javovsky
>>> proces ukonci a vrati cely blok pameti do OS.
>>>
>>> Tj k volani finalize nedojde vubec.
>>>
>>> LZ
>>>
>>> 2009/2/24 Tomas Studva <tstudva na gmail.com>:
>>>> To kedy sa dealokovalo f, zaviselo od velkosti pola, cize ci sa este  
>>>> pred
>>>> cyklom automaticky spustilo gc.
>>>>
>>>> Treba si vsak uvedomit ze kompilator nemoze takmer vobec ovplyvnit
>>>> dealokaciu - ak by bol predposledny prikaz bloku volanie nejakej  
>>>> metody, tak
>>>> uz nik nevie co sa stalo. Nejako vsak ten gc vie ze na f uz nic  
>>>> neukazuje,
>>>> alebo je v inej generacii ako stuff. Napada mi reference counting,  
>>>> ale to sa
>>>> zevraj nepouziva v gc-ckach (viem ale ze ref-count. napr. pouziva  
>>>> Cocoa).
>>>>
>>>> Zdenek Tronicek  wrote / napísal(a):
>>>>>
>>>>> Ja jsem popisoval, jak se chova JVM za "normalnich" podminek. V  
>>>>> okamziku,
>>>>> kdy zacne dochazet pamet, zacne JVM drsne optimalizovat. A ze to  
>>>>> umi, lze
>>>>> videt na tomto prikladu (z Vaseho kodu jsem vypustil blok):
>>>>>
>>>>>        System.out.println("start");
>>>>>        // vytvorim Foo
>>>>>        Foo f = new Foo(null);
>>>>>        // vytvorim pole Stuff
>>>>>        Stuff[] theStuffs = new Stuff[100000];
>>>>>        for (int i = 0; i < theStuffs.length; i++) {
>>>>>            theStuffs[i] = new Stuff();
>>>>>        }
>>>>>        // nez se dojde sem, je po objektu f
>>>>>        while (true) {
>>>>>            System.out.println("aaa");
>>>>>            Runtime.getRuntime().gc();
>>>>>            try {
>>>>>                Thread.sleep(200);
>>>>>            } catch (InterruptedException e) {
>>>>>                // TODO Auto-generated catch block
>>>>>                e.printStackTrace();
>>>>>            }
>>>>>        }
>>>>>
>>>>> Na mem pocitaci dojde k dealokaci objektu f jeste drive, nez se  
>>>>> vstoupi do
>>>>> smycky while. Jak k tomu muze dojit? Java neco takoveho neumoznuje,  
>>>>> jde
>>>>> ciste o optimalizaci JVM.
>>>>> Mimochodem, myslim, ze tohle je na hranici toho, co jeste lze delat,
>>>>> protoze kdyby nejaky program spolehal na to, ze objekt nemuze byt  
>>>>> dealokovan
>>>>> pred koncem platnosti promenne f (tj. pred koncem metody), nebude  
>>>>> fungovat.
>>>>>
>>>>> Pokud jde o ty lokalni promenne, tak ve vypise javap je jejich pocet  
>>>>> za
>>>>> retezcem Locals= a po dobu vykonavani metody se tato hodnota nemeni.
>>>>>
>>>>> Z.T.
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>> --Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/