[java] Test MyClass = new Test() hoe free maken?

[Hu9o]

Hallo ik heb de vraag eigelijk al in het subject gezet.

Ik maak een Test Class aan. Maar deze moet natuurlijk ook weer worden vrij gegeven. Hoe moet dat?

MyClass.Free werkt niet

[.oisyn]

hoe bedoel je "vrij gegeven"?

als je het geheugen enzo bedoelt, gewoon alle referenties naar die instantie weghalen. Dus MyClass op null zetten.

Vervolgens haalt de garbage collector 'm (ooit) weg, hoewel er geen tijdsgarantie aan vast zit (volgens mij zelfs geen garantie dat ie uberhaupt wordt vrijgemaakt)

[Woy]

Je moet denk maar even naar de Garbage Collector zoeken. In java worden je resources automagisch weer vrijgegeven op het moment dat je geen referentie meer naar een object hebt

[Bobco]

Wat wil je precies doen? Als het er om gaat dat dat het aangemaakte Object echte weggegooid wordt dan heb je geen garanties. Op het moment dat je zegt

code:

Test myTest = new Test();
mytest = null;

Dan wordt het object waar jouw variabele myTest naar verwees een kandidaat voor Garbage Collection. Er zijn geen garanties voor of en wanneer dit gebeurt. Java kent ook geen destructors zoals die in andere talen voorkomen.

Tip: In Java worden namen van classes met een hoofdletter geschreven, namen van variabelen met een kleine...

[Hu9o]

Ok bedankt.

Ik ben meer thuis in Delphi, en daar moet je een zelf gemaakt object ook weer uit het geheugen halen. In Java gebeurt dit dus vanzelf een keer.

[.oisyn]

[nohtml]

Bobco schreef op 13 November 2002 @ 15:40:
Java kent ook geen destructors zoals die in andere talen voorkomen.

java kent de methode finalize ()

[Verwijderd]

Ik ben meer thuis in Delphi

Dat zag ik al aan het "free-en" van classes

In Java gebeurt dit dus vanzelf een keer.

Nee, dit gebeurt direct wanneer ze niet meer nodig zijn Er zijn meerdere talen waar dit het geval is zoals PHP, etc.

In het vervolg wel eerst ff goed zoeken he (google, etc)

[Soultaker]

.oisyn schreef op 13 November 2002 @ 15:44:
java kent de methode finalize ()

...maar dat is nauwelijks een "destructor zoals die in andere talen voorkomt" te noemen. Je weet nooit zeker of je destructor aangeroepen wordt en zo ja, wanneer, en of er een logische volgorde in de aanroepen van de destructors zit. Typische toepassingen, zoals een Connection klasse die in de destructor een open socket afsluit, zijn niet met finalize meestal niet goed uit te voeren.

[Bobco]

.oisyn schreef op 13 November 2002 @ 15:44:
[nohtml]
[...]
java kent de methode finalize ()

Ja, maar die is bedoeld om door de GC aangeroepen te worden als het object inderdaad verwijderd wordt. Omdat je totaal niets weet van de volgorde waarin finalize() wordt aangeroepen op objecten die kandidaat zijn voor Gabage Collection is het niet echt een betrouwbaar mechanisme om resources vrij te geven. Dit artikel op JavaWorld geeft hier wat meer achtergrond over.

Het enige dat je met goed fatsoen kan doen is wat je eigenlijk altijd moet doen: resources vrij geven op het moment dat je ze niet meer nodig hebt. Natuurlijk is dat slecht voor je performance, maar zoals het spreekwoord zegt: "Het kan goed, snel of volledig. Kies er twee..."

[Soultaker]

Verwijderd schreef op 13 november 2002 @ 15:49:
Nee, dit gebeurt direct wanneer ze niet meer nodig zijn Er zijn meerdere talen waar dit het geval is zoals PHP, etc.

Nee, dat gebeurt niet direct wanneer ze niet meer nodig zijn. In Java draait een aparte low-priority thread mee bij de executie van het programma, die continue op zoek is naar objecten die opgeruimd mogen worden. In specifieke situaties kan het echter relatief lang duren voordat deze garbage collector de overbodig geworden objecten vindt. Het is dus zeker niet zo dat ze 'direct' opgeruimd worden. (Uiteraard krijgt de garbage collector een hogere prioriteit wanneer het geheugen op dreigt te raken, maar dit terzijde.)

[ Voor 0% gewijzigd door Soultaker op 13-11-2002 15:55 . Reden: d/t-regel is ingewikkeld ]

[drm]

ridde100:
Nee, dit gebeurt direct wanneer ze niet meer nodig zijn Er zijn meerdere talen waar dit het geval is zoals PHP, etc.

In Java Hoe kom je daar bij?

[Bobco]

In aanvulling op de dingen die hier al genoemd zijn: het is ook mogelijk om gebruik te maken van zgn ShutdownHooks. Dit zijn eigenlijk threads die gestart worden door de runtime environment op het moment dat de JVM stopt. Die dingen kunnen nuttig zijn als je op het allerlaatste moment nog resources vrij wilt geven. Voor meer informatie kun je de JavaDoc voor Runtime.addShutdownHook(Thread hook)bekijken.

[.oisyn]

Soultaker schreef op 13 november 2002 @ 15:52:
[...]

...maar dat is nauwelijks een "destructor zoals die in andere talen voorkomt" te noemen. Je weet nooit zeker of je destructor aangeroepen wordt en zo ja, wanneer, en of er een logische volgorde in de aanroepen van de destructors zit. Typische toepassingen, zoals een Connection klasse die in de destructor een open socket afsluit, zijn niet met finalize meestal niet goed uit te voeren.

Bobco schreef op 13 november 2002 @ 15:54 eenzelfde soort verhaal

Het is in die zin een destructor dat het wordt aangeroepen als het object wordt gedestruct. Dat je niet weet of en wanneer is een gevolg van het garbage collection systeem in java (wat ik al in de eerste reactie in deze thread zei). Zeggen dat java geen destructor kent vind ik dus onzin. Dat die destructor verder niet echt zinnig is door de manier van garbage collection is weer een ander verhaal

[Bobco]

.oisyn schreef op 13 November 2002 @ 15:59:

[...]



[...]
Het is in die zin een destructor dat het wordt aangeroepen als het object wordt gedestruct. Dat je niet weet of en wanneer is een gevolg van het garbage collection systeem in java (wat ik al in de eerste reactie in deze thread zei). Zeggen dat java geen destructor kent vind ik dus onzin. Dat die destructor verder niet echt zinnig is door de manier van garbage collection is weer een ander verhaal

Ha, discussie! Ik vind finalize() geen destructor, omdat het niet iets is wat je expliciet kan aanroepen. Dit is uiteraard helemaal in de geest van de manier waarop Java met geheugen omgaat: je ziet het niet en kunt er als Java-programmeur dus ook geen smerige trucs mee uithalen die in andere talen wel kunnen (en wel degelijk hun nut kunnen hebben, maar dit is een andere discussie).

Je kunt als codeklopper in Java simpelweg niet afdwingen dat een object al z'n resources (lees: geheugen) vrij geeft. Dit staat volledig onder controle van de JVM.
Blijft over de stelling over dat er geen expliciete destructor in Java bestaat. De enige manier waarop je finalize() kan laten aanroepen is door alle referenties weg te gooien en dan maar duimen dat de GC 'm pakt...

[.oisyn]

Waarom zou je een destructor expliciet moeten kunnen aanroepen? Dus volgens jou is een private destructor in C++ geen destructor? (je kunt m immers niet aanroepen). Wat ik onder een destructor versta is een lap code (functie, methode) dat uitgevoerd wordt als een object opgeruimd moet worden. Nou werd ik echter net op de hoogte gebracht door Gliempo ( ) dat je de destruction kunt cancelen door weer een referentie te creeeren naar dit object. Dit wist ik niet, en dit maakt het wel een mindere destructor dan in een taal zoals C++

[Glimi]

.oisyn schreef op 13 november 2002 @ 15:59:
Het is in die zin een destructor dat het wordt aangeroepen als het object wordt gedestruct. Dat je niet weet of en wanneer is een gevolg van het garbage collection systeem in java (wat ik al in de eerste reactie in deze thread zei). Zeggen dat java geen destructor kent vind ik dus onzin. Dat die destructor verder niet echt zinnig is door de manier van garbage collection is weer een ander verhaal

Niet echt mee eens. Laten we een destructor zo defnieren: "de methode wordt uitgevoerd en daarna wordt het object vernietigd"

Als ik dan in de api van java ga bladeren vind ik dit bij de finalize() methode van Object:

The finalize method may take any action, including making this object available again to other threads; the usual purpose of finalize, however, is to perform cleanup actions before the object is irrevocably discarded.
(...)
The finalize method of class Object performs no special action; it simply returns normally. Subclasses of Object may override this definition.

Dus hoewel finalize() meestal wordt gebruikt als destructor, is het dus mogelijk om in finalize() het object te behouden van desturctie! En dat maakt finalize() dus eigenlijk geen destructor in mijn oogpunt

NB. let wel op dat finalize() altijd maar 1x wordt aangeroepen. Stel er referenced niets meer naar a en a's finalize() methode zorgt ervoor dat toch wel iets naar a referenced, dan wordt a niet opgeruimd daarna. Mocht er echter daarna ooit geen verwijzing meer bestaan naar a, dan wordt finalize() niet uitgevoerd en a gewoon opgeruimd.

edit:
Ik moet m'n muil houwen op IRC

[Bobco]

.oisyn schreef op 13 November 2002 @ 16:15:
Waarom zou je een destructor expliciet moeten kunnen aanroepen? Dus volgens jou is een private destructor in C++ geen destructor? (je kunt m immers niet aanroepen).

Weer een reden om C++ links te laten liggen

Wat ik onder een destructor versta is een lap code (functie, methode) dat uitgevoerd wordt als een object opgeruimd moet worden. Nou werd ik echter net op de hoogte gebracht door Gliempo ( ) dat je de destruction kunt cancelen door weer een referentie te creeeren naar dit object. Dit wist ik niet, en dit maakt het wel een mindere destructor dan in een taal zoals C++

Mja, ik denk dat we wat dat betreft een verschillend gevoel hebben bij de kreet 'destructor'. Ik zie het meer als een aanroep die direct en zonder omwegen een object wegknikkert zonder dat er iets van overblijft.

[ACM]

Verwijderd schreef op 13 november 2002 @ 15:49:
Nee, dit gebeurt direct wanneer ze niet meer nodig zijn Er zijn meerdere talen waar dit het geval is zoals PHP, etc.

In het vervolg wel eerst ff goed zoeken he (google, etc)

Garbage collection in php??

Volgens mij bestaat dat nog niet.

[.oisyn]

Gliempo schreef op 13 november 2002 @ 16:17 een verhaal

dat zeg ik toch:

.oisyn schreef op 13 november 2002 @ 16:15:
[..] Nou werd ik echter net op de hoogte gebracht door Gliempo ( ) dat je de destruction kunt cancelen door weer een referentie te creeeren naar dit object. Dit wist ik niet, en dit maakt het wel een mindere destructor dan in een taal zoals C++

[Glimi]

Bobco schreef op 13 november 2002 @ 16:18:
Weer een reden om C++ links te laten liggen

Omdat C++ access modifiers heeft? Rare reden imho
Het blijft gewoon een destructionfunction imho

Mja, ik denk dat we wat dat betreft een verschillend gevoel hebben bij de kreet 'destructor'. Ik zie het meer als een aanroep die direct en zonder omwegen een object wegknikkert zonder dat er iets van overblijft.

Dus als je het niet kan aanroepen is het geen destructor meer? Een destructor is toch gewoon een functie die wordt aangeroepen vlak voordat het object vernietigd gaat worden?

[.oisyn]

Bobco schreef op 13 November 2002 @ 16:18:
Weer een reden om C++ links te laten liggen

als ik ergens een hekel aan heb dan is het wel het niet weten wanneer of zelfs niet weten OF een object wordt opgeruimd. En als het niet meteen opgeruimd moet worden kan het zo in een queue gegooid worden, geen probleem

Mja, ik denk dat we wat dat betreft een verschillend gevoel hebben bij de kreet 'destructor'. Ik zie het meer als een aanroep die direct en zonder omwegen een object wegknikkert zonder dat er iets van overblijft.

Een destructor gooit een object niet weg, maar ruimt het simpelweg op (dan bedoel ik alles wat het object vasthoudt, maar niet zichzelf). Een destructor in C++ geeft het geheugen dan ook niet vrij (zou ook niet kunnen, aangezien een destructor niet weet of het object op de stack of op de heap is geallocceert)

[Verwijderd]

ACM schreef op 13 november 2002 @ 16:19:

[...]

Garbage collection in php??

Volgens mij bestaat dat nog niet.

Bestaat idd niet Mssn was ik te snel met mijn post: Ik bedoelde dat je in PHP niet hoeft te destructen.

[.oisyn]

ho, reactie gemist

ACM schreef op 13 november 2002 @ 16:19:
Garbage collection in php??

Volgens mij bestaat dat nog niet.

Ook PHP kent een vrij simplistische garbage collection, dmv reference counting.

[Soultaker]

.oisyn schreef op 14 November 2002 @ 00:19:
Ook PHP kent een vrij simplistische garbage collection, dmv reference counting.

Praktische ervaring doet vermoeden dat zelfs dit niet werkt en als het officieel wel werkt, lijkt het in de praktijk niet tot het serieus opruimen van geheugen te leiden. De meeste wat meer complexere 'applicaties' in PHP gaan steeds meer geheugen gebruiken tot ze crashen. Dat kan natuurlijk ook omdat er elke keer weer een paar cyclische referenties tussen nieuwe objecten ontstaan. Ik betwijfel echter of het nuttig is om reference counting allleen te implementeren: je hebt dan ZOWEL een traag systeem ALS een systeem wat niet voor 100% werkt (en ook niet voor 99%).

[.oisyn]

Soultaker schreef op 14 November 2002 @ 02:25:

Praktische ervaring doet vermoeden dat zelfs dit niet werkt en als het officieel wel werkt, lijkt het in de praktijk niet tot het serieus opruimen van geheugen te leiden. De meeste wat meer complexere 'applicaties' in PHP gaan steeds meer geheugen gebruiken tot ze crashen. Dat kan natuurlijk ook omdat er elke keer weer een paar cyclische referenties tussen nieuwe objecten ontstaan. Ik betwijfel echter of het nuttig is om reference counting allleen te implementeren: je hebt dan ZOWEL een traag systeem ALS een systeem wat niet voor 100% werkt (en ook niet voor 99%).

ik weet niet of je php weleens van binnen hebt gezien, maar echt, dat is dus driewerf bagger. Die lui hebben nog nooit gehoord van codeconventions, en ik heb echt het idee dat ze maar wat aanprutsen. Als je een php module wilt ontwikkelen dan belandt je in een wereld die samenhangt dmv allerlei ranzige macro's, waarbij je de ene keer wel een semicolon erachter moet zetten, en de andere keer weer niet. Het toppunt vind ik nog wel deze:

The prototype for parameter parsing function looks like this:

C:

int zend_parse_parameters(int num_args TSRMLS_DC, char *type_spec, ...);

(let op die missende komma na de eerste parameter). De aanroep van deze functie moet alsvolgt:

C:

if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC,
                          "lsz", &l, &s, &s_len, ¶m) == FAILURE)
{
    ...
}

(let weer op die missende komma)
Dan ga je eens kijken waar TSRMLS_CC gedeclareert is, kom je op deze define:

#define TSRMLS_CC , TRMLS_C



anyway, dit alles bij elkaar en je kunt je goed voorstellen dat ook al zou het moeten werken het toch eigenlijk niet werkt (en dan te bedenken dat de engine al 2x from scratch geschreven is)

[Verwijderd]

Nog ff een late reply. Java kent speciale references waardoor objecten direct door de gc worden opgeruimd.

Dit:

code:

Test test = (Test)new java.lang.ref.WeakReference(new Test()).getObject();
System.gc();

Zou ervoor moeten zorgen dat new Test() gewoon wordt opgeruimd.

Overigens heeft Sun weer flink gesleuteld aan de garbage collector. Als je meer wil weten over garbage collection moet je hier eens kijken.

[Bobco]

.oisyn schreef op 13 november 2002 @ 16:27:
Een destructor gooit een object niet weg, maar ruimt het simpelweg op (dan bedoel ik alles wat het object vasthoudt, maar niet zichzelf). Een destructor in C++ geeft het geheugen dan ook niet vrij (zou ook niet kunnen, aangezien een destructor niet weet of het object op de stack of op de heap is geallocceert)

Tja, mijn C++ kennis is zeeeer beperkt. Ik blijf het lastig vinden dat als je een 'destructor' aanroept er toch nog systeem resources (geheugen) vastgehouden kunnen worden door een object dat je net om zeep hebt geholpen.

Maar om even terug te komen op de manier waarop Java dit allemaal geregeld heeft: het enige dat van belang is, is dat je geen onnodige referenties bijhoudt. Als er aan GC gedaan wordt dan kun je er redelijk zeker van zijn dat er netjes opgeruimd wordt, exotische situaties als een object A en B die naar elkaar refereren waarbij er verder geen enkele referentie naar A of B meer is buiten beschouwing gelaten.

[mbravenboer]

websjwans: Dit zou ervoor moeten zorgen dat new Test() gewoon wordt opgeruimd.

Ik vrees van niet . Een WeakReference is bedoeld om de garbage collection van objecten niet in de weg te staan: je hebt er een referentie naar, maar wat jou betreft mag hij hier wel verloren gaan. De WeakReference 'telt' niet mee als het om het detecteren van niet bereikbare objecten gaat. Het object in de WeakReference zal daardoor (ooit) pas null worden als er geen andere normale referentie naar het object meer is. In dit geval zie ik dat je nog een normale referentie naar het gemaakte object hebt en daardoor zal het object in de WeakReference niet opgeruimd worden.

[.oisyn]

Bobco schreef op 14 November 2002 @ 09:28:
Tja, mijn C++ kennis is zeeeer beperkt. Ik blijf het lastig vinden dat als je een 'destructor' aanroept er toch nog systeem resources (geheugen) vastgehouden kunnen worden door een object dat je net om zeep hebt geholpen.

in C++ roep je een destructor zelden zelf aan. Dit gaat meestal automatisch als het object buiten scope gaat, of als je gebruik maakt van de delete operator. De delete operator roept vervolgens de destructor aan, en geeft daarna het geheugen vrij

exotische situaties als een object A en B die naar elkaar refereren waarbij er verder geen enkele referentie naar A of B meer is buiten beschouwing gelaten.

zo exotisch vind ik dit niet, het komt regelmatig in mijn projecten voor (maar dan meer in de zin van een parent-child relatie, wederom in C++ overigens ). De GC van java kan trouwens prima met cyclische verwijzingen overweg