Capisco che Rust non abbia un garbage collector e mi chiedo come viene liberata la memoria quando un binding esce dall'ambito.
Quindi in questo esempio, capisco che Rust recupera la memoria assegnata a "a" quando esce dall'ambito.
{
let a = 4
}
Il problema che sto avendo con questo, è in primo luogo come questo accade, e in secondo luogo non è una sorta di garbage collection? In cosa differisce dalla "tipica" raccolta dei rifiuti?
Risposte:
La garbage collection viene in genere utilizzata periodicamente o su richiesta, ad esempio se l'heap è vicino al pieno o al di sopra di una certa soglia. Quindi cerca le variabili inutilizzate e libera la loro memoria, a seconda dell'algoritmo .
Rust saprebbe quando la variabile esce dall'ambito o la sua durata termina al momento della compilazione e quindi inserisce le corrispondenti istruzioni LLVM / assembly per liberare la memoria.
Rust consente anche una sorta di garbage collection, come il conteggio dei riferimenti atomici .
new()funzione unta come C, sono solo funzioni statiche, e in particolare qualcosa come let x = MyStruct::new()crea il suo oggetto sullo stack. Il vero indicatore dell'allocazione dell'heap è Box::new()(o una qualsiasi delle strutture che dipendono da Box).
L'idea di base della gestione delle risorse (inclusa la memoria) in un programma, qualunque sia la strategia, è che le risorse legate ad "oggetti" irraggiungibili possono essere recuperate. Oltre alla memoria, queste risorse possono essere blocchi mutex, handle di file, socket, connessioni al database ...
Le lingue con un garbage collector analizzano periodicamente la memoria (in un modo o nell'altro) per trovare oggetti inutilizzati, rilasciare le risorse ad essi associate e infine rilasciare la memoria utilizzata da quegli oggetti.
Rust non ha un GC, come gestisce?
Rust ha la proprietà. Utilizzando un sistema di tipo affine , tiene traccia di quale variabile sta ancora trattenendo un oggetto e, quando tale variabile esce dall'ambito, chiama il suo distruttore. Puoi vedere il sistema di tipi affini in vigore abbastanza facilmente:
fn main() {
let s: String = "Hello, World!".into();
let t = s;
println!("{}", s);
}
Rendimenti:
<anon>:4:24: 4:25 error: use of moved value: `s` [E0382]
<anon>:4 println!("{}", s);
<anon>:3:13: 3:14 note: `s` moved here because it has type `collections::string::String`, which is moved by default
<anon>:3 let t = s;
^
il che illustra perfettamente che in qualsiasi momento, a livello di lingua, la proprietà viene tracciata.
Questa proprietà funziona in modo ricorsivo: se si dispone di un Vec<String>(ovvero, un array dinamico di stringhe), ciascuna Stringè di proprietà del Vecquale a sua volta è di proprietà di una variabile o di un altro oggetto, ecc ... quindi, quando una variabile esce dall'ambito, libera ricorsivamente tutte le risorse che aveva, anche indirettamente. In questo caso Vec<String>significa:
StringVecstessoPertanto, grazie al rilevamento della proprietà, la durata di TUTTI gli oggetti del programma è strettamente legata a una (o più) variabili di funzione, che alla fine usciranno dall'ambito (quando il blocco a cui appartengono termina).
Nota: questo è un po 'ottimistico, utilizzando il conteggio dei riferimenti ( Rco Arc) è possibile formare cicli di riferimenti e quindi causare perdite di memoria, nel qual caso le risorse legate al ciclo potrebbero non essere mai rilasciate.
Con un linguaggio in cui è necessario gestire manualmente la memoria, la distinzione tra stack e heap diventa fondamentale. Ogni volta che chiamate una funzione, nello stack viene allocato uno spazio sufficiente per tutte le variabili contenute nell'ambito di tale funzione. Quando la funzione ritorna, lo stack frame associato a quella funzione viene "estratto" dallo stack e la memoria viene liberata per un utilizzo futuro.
Da un punto di vista pratico, questa pulizia involontaria della memoria viene utilizzata come mezzo di memorizzazione automatica della memoria che verrà cancellata al termine dell'ambito della funzione.
Ulteriori informazioni sono disponibili qui: https://doc.rust-lang.org/book/the-stack-and-the-heap.html