L'assegnazione di NULL in un ambiente GC ha effetti simili all'uso di free ()?

Question

L'assegnazione di NULL in un ambiente GC ha effetti simili all'uso di free ()?

#1 da (11 voti)

6

Stavo solo scrivendo una funzione (in C # in questo caso) che memorizzava enormi quantità di dati in una variabile locale nelle prime fasi del codice, diciamo al 5% del codice delle funzioni.
Dopo quel punto, i dati in questo memeory non sono più usati,
anche il seguente 95% di codice ha un runtime variabile, in quanto parte di esso dipende da risorse esterne.
La mia idea era (ispirata a C) di "liberare attivamente" quel blocco di memoria.
In un ambiente con un GC questo è per lo più semplicemente impossibile.

La mia idea:
memeoryMonster = null;
Perché questo?
Il GC non raccoglierebbe mai quell'oggetto mentre l'esecuzione è ancora all'interno della funzione, poiché la variabile è ancora in ambito e quindi connessa al grafico dell'oggetto.
Questa riga rimuoverà il riferimento all'oggetto e quindi lo scollegherà dal grafico dell'oggetto.
Non sto chiamando attivamente il GC, ma sappiamo che viene eseguito se la memoria si esaurisce, che potrebbe accadere nella seconda parte della funzione o in qualsiasi momento
o tutti gli altri thread sono inattivi, cosa che potrebbe accadere molto bene quando il codice attende le risorse esterne i.e ..
In questo modo voglio che il GC sia in grado di raccogliere quella memoria, se necessario.

Inoltre mi rendo conto che è probabilmente meglio dividere quella funzione in più parti, che ho già fatto, o almeno impacchettare la parte di memoria in una coppia di {} per far sì che ottenga il proprio ambito, quindi la domanda è di natura teoretica.

La mia domanda:
Funziona come penso che faccia?
L'impostazione delle variabili locali su NULL consente al GC di raccogliere la memoria che occupavano?

memory garbage-collection allocation

posta Mark 28.10.2014 - 07:20

fonte

1 risposta

Leggi altre domande sui tag memory garbage-collection allocation

È etico adottare gli algoritmi di altri programmatori? Chi dovrebbe supportare e mantenere l'infrastruttura di sviluppo?

score 11 · Accepted Answer

Non lo direi, ma la tua spiegazione nel mezzo del testo della domanda è fondamentalmente sana.

In primo luogo, l'oggetto può essere raggiungibile attraverso un altro riferimento. Questo dovrebbe essere ovvio, ma è un comune errore da principiante "rendere l'oggetto nullo" quando ci sono altri tre riferimenti nella stessa funzione.

In secondo luogo, in alcuni ambienti (.NET è un esempio fuori dalla mia testa), l'ottimizzatore può molto bene rilasciare il riferimento prima della fine del suo ambito se non viene mai utilizzato attraverso il secondo 95% del codice. Se è così, è ridondante.

Infine, free è una cattiva analogia. Capisco perché l'hai scelto, e questo è più di un nitpick, e tu lo esprimi meglio in altre parti della tua risposta, ma pensarlo come un analogo a free non è utile IMHO. Non è tempestivo, è possibile solo abilita deallocation invece di forzarlo (vedi il punto sopra relativo ad altri riferimenti), e un% non corretto di = null non è così pericoloso come free() fuori posto.

Dopo tutti questi avvertimenti però, sì, se una variabile locale è l'unico riferimento raggiungibile a un oggetto (grafico), impostarla su null consentirà al GC di raccogliere quegli oggetti in precedenza se il GC viene eseguito tra l'assegnazione nulla e la fine dell'ambito della variabile. Com'è comune questa situazione è tutta un'altra questione, tra le altre cose dipende da quanti oggetti vengono creati dal resto del codice. Nella mia esperienza, questa è una situazione estremamente rara, da qui il mio scetticismo se questa azione è necessaria.