Gestion de la mémoire en Rust : pourquoi pas de ramasse-miettes et comment ça fonctionne

Formateur Python en ligne pour débutants

Apprenez Python facilement sans surcharge théorique. Résolvez des tâches pratiques avec vérification automatique et écrivez du code directement dans le navigateur.

Start Course

Qu'est-ce qu'un ramasse-miettes et pourquoi Rust y a-t-il renoncé ?

\n\n

Si vous venez du monde Python, Java ou C#, vous avez l'habitude que la mémoire soit gérée par un ramasse-miettes (Garbage Collector, GC). C'est un « nettoyeur » invisible qui vérifie périodiquement quels objets ne sont plus utilisés et libère la mémoire qu'ils occupent. Pratique ? Oui. Mais il y a des nuances :

\n\n
    \n
  • Pauses imprévisibles. Le GC peut se lancer au pire moment — lorsque votre code traite une requête importante ou rend une image dans un jeu.
  • \n
  • Surcharge mémoire. Le GC nécessite souvent de la mémoire supplémentaire pour son fonctionnement.
  • \n
  • Complexité dans les systèmes temps réel. Dans les systèmes d'exploitation, les pilotes ou les appareils embarqués, les pauses du GC sont inacceptables.
  • \n
\n\n

Rust propose une approche radicalement différente. Au lieu d'un ramasse-miettes, on utilise un système de possession (ownership) qui fonctionne à l'étape de compilation. Le compilateur décide lui-même quand la mémoire doit être libérée, et le fait sans aucune surcharge d'exécution. Voyons comment cela fonctionne.

\n\n

Système de possession (Ownership) — la base de la gestion de la mémoire

\n\n

En Rust, chaque valeur a exactement un propriétaire — la variable à laquelle cette valeur appartient. Lorsque le propriétaire sort de la portée (scope), la mémoire est automatiquement libérée. Pas de ramasse-miettes, pas de comptage de références — seulement le compilateur et des règles strictes.

\n\n

Règles de possession en Rust

\n\n

Voici les trois règles principales que le compilateur vérifie à l'étape de compilation :

\n\n
    \n
  • Chaque valeur en Rust a un seul propriétaire.
  • \n
  • Lorsque le propriétaire sort de la portée, la valeur est supprimée (drop).
  • \n
  • La valeur peut être transférée à un autre propriétaire (move) ou empruntée (borrow).
  • \n
\n\n
fn main() {\n    let s1 = String::from("Hello"); // s1 — propriétaire de la chaîne\n    let s2 = s1;                     // La possession PASSE à s2 (move)\n    // println!("{}", s1);           // Erreur ! s1 ne possède plus la chaîne\n    println!("{}", s2);             // Ok : s2 est le nouveau propriétaire\n} // Ici, s1 et s2 sortent de la portée,\n  // mais la mémoire est libérée une seule fois — pour s2
\n\n

En Python ou Java, vous auriez simplement créé une autre référence à l'objet, et le GC s'en serait occupé plus tard. En Rust — pas de surprises : le compilateur garantit que la mémoire sera libérée exactement une fois.

\n\n

Emprunt (Borrowing) — comment utiliser les données sans transférer la possession

\n\n

Nous avons souvent besoin d'« emprunter » temporairement l'accès aux données, sans les retirer à leur propriétaire. Pour cela, Rust dispose de références (references). Il en existe deux types :

\n\n
    \n
  • Références immuables (&T) : on peut lire les données, mais pas les modifier.
  • \n
  • Références mutables (&mut T) : on peut lire et modifier, mais seulement s'il n'y a pas d'autres références actives.
  • \n
\n\n
fn main() {\n    let mut text = String::from("Rust");\n    \n    let r1 = &text;     // référence immuable\n    let r2 = &text;     // une autre référence immuable — possible\n    println!("{} {}", r1, r2);\n    \n    let r3 = &mut text; // référence mutable — fonctionne car r1 et r2 ne sont plus utilisées\n    r3.push_str(" rocks!");\n    println!("{}", r3);\n    \n    // Mais ceci n'est pas possible :\n    // let r1 = &text;\n    // let r3 = &mut text; // Erreur ! Impossible d'avoir une référence mutable et immuable simultanément\n}
\n\n

Le compilateur Rust n'est pas qu'un simple analyseur statique, c'est un enseignant strict mais juste. Il ne vous laissera pas vous tirer une balle dans le pied. Si vous essayez de créer une référence mutable alors qu'il existe des références immuables, vous obtiendrez une erreur de compilation. C'est le travail du borrow checker — le mécanisme qui remplace le

Blogs

Book Recommendations