[JAVA] Classe a Runtime

[spv42]

Salve

Volevo sapere se è possibile saper a runtime se un 'istanza di un ogetto (mia classe) è presente nell'heap (in pratica se è stato invocato il costruttore).

Grazie

[tony.www]

ci sarebbe l'operatore booleano istanceof che controlla il tipo di oggetto referenziato a run-time...L'ho sparata lì spero di esserti stato utile :)

[Oceans11]

anch'io voglio spararla!!! :D

visto che la classe che vuoi controllare è tua....che ne dici di un intero statico che incrementi nel costruttore???

è semplice e dovrebbe funzionare!

ah e se però l'oggetto è stato garbaggiato??? :rolleyes:
boh! :mc:

[ocean_id]

ah e se però l'oggetto è stato garbaggiato??? :rolleyes:
boh! :mc:

basta rendere statico il campo dati in questione. :)
un contatore che viene aumentato dai costruttori della classe e decrementato dal distruttore.

[^TiGeRShArK^]

attenzione alla concorrenza però....

[spv42]

basta rendere statico il campo dati in questione. :)
un contatore che viene aumentato dai costruttori della classe e decrementato dal distruttore.

Scusa la mia ignoranza, ma Il Distruttore in Java come si implementa?

[PGI-Bis]

Nella piattaforma standard di norma non è necessario usare delle procedure di distruzione.

Un'eccezione è quella che nasce dalla presenza di una controparte nativa. Genere "te la sei cercata". Se un oggetto è definito in parte in Java e in parte in C\C++, tramite JNI, allora al rilascio della memoria "dinamica" occupata dalla porzione Java dell'oggetto occorre affiancare il rilascio della memoria eventualmente allocata dalla porzione C\C++.

Per farlo è possibile ridefinire il metodo finalize(): super.finalize() e poi invochi il metodo nativo che chiama il distruttore della controparte C\C++.

Il metodo finalize è invocato dal garbage collector quando un oggetto cessa di essere raggiungibile. Il momento in cui il metodo finalize() sarà invocato non è decidibile a priori: spetta al garbage collector stabilire quanto l'occasione sia propizia. Esiste un metodo in System, gc, che millanta la possibilità di "attizzare" il garbage collector ma è più una proposta che un ordine.

Accanto alla liberazione operata nel metodo finalize è bene predisporre un metodo ad hoc (close, release, flush, dispose, i nomi che girano sono questi) in modo tale da consentire all'utente di rilasciare risorse anche prima che il garbage collector invochi finalize.

L'esistenza di un metodo ad hoc è motivata dal comportamento del garbage collector della piattaforma standard. Funziona "a due velocità". Se un oggetto diventa irraggiungibile pochi istanti dopo la sua creazione allora viene "disintegrato" all'istante. Se un oggetto sopravvive per un certo periodo di tempo allora il rilascio delle risorse (e quindi l'invocazione del suo metodo finalize) tende ad essere posticipato.

E' importante tuttavia che questo metodo ad hoc sia affiancato e non si sostuisca alla liberazione tramite introduzione di opportune istruzioni nel metodo finalize, altrimenti si delega all'utente della classe la responsabilità di assicurare la corretta gestione della memoria e la vita, si sa, è troppo breve per perdere tempo in queste cose.

[mad_hhatter]

e il metodo ad hoc di preciso cosa fa? cioè in che senso libera risorse in maniera indipendente dal gc?

[PGI-Bis]

Fa la stessa cosa che farebbe finalize, ma lo fa "a comando". E' possibile, ad esempio, che il metodo ad hoc invochi una funzione nativa che libera memoria o altre risorse. Tipo il close dei canali e flussi. Ma nulla vieta che siano resi eliminabili oggetti il cui unico scopo sia rendere più rapido un certo tipo di accesso al dato "reale", come avviene per le cache. In questo secondo caso, tuttavia, il rilascio non deve essere inteso come immediato ma è sempre soggetto ai tempi e ai modi del garbage collector.

Supponiamo ad esempio che io abbia un programma che invia a richiesta dei file. Potrei decidere di tenere in memoria gli ultimi cinque file serviti, usando dei ByteBuffer. Non sarebbe una cattiva idea dotare quest'oggetto "cache" di un metodo "dispose()" che prende e reindirizza i cinque ByteBuffer su null. Assegnare null ad un riferimento non significa liberare memoria, in Java. Significa dire "per questo oggetto non è più raggiungibile". Nel caso in cui sia vero (il garbage collector è un volpone) e quando sarà il caso, il garbage collector provvederà a revocare lo spazio assegnato a quei ByteBuffer.

"Quando sarà il caso" significa non si sa quando ma si sa che prima di sparare un'eccezione out of memory il garbage collector avrà avocato a sè ogni goccia di memoria disponibile.

[mad_hhatter]

ah ecco... il discorso di settare a null e aspettare i gc era il modo "classico" a cui pensavo, ma quando hai parlato di metodi adhoc x liberare la memoria pensavo a meccanismi che si sostituissero al gc :) cm appunto i metodi nativi da te nominati e a cui io non avevo pensato.

grazie!