Rc / Arc, ou le partage par comptage de références Rc / Arc, or sharing by reference counting

Plusieurs propriétaires pour une donnée — tant qu'il en reste un, elle vit.Several owners for one piece of data — as long as one remains, it lives.

Box a déporté la donnée sur le tas sans toucher à la règle d'or : un seul propriétaire. Mais certaines structures ne sont pas des arbres. Un graphe où deux nœuds pointent le même voisin ; un cache qu'un service et son journal consultent tous deux ; une donnée dont on ne sait pas, à la compilation, qui la libérera en dernier. L'arbre du Vol 1 ne peut pas l'exprimer — il faudrait deux parents pour une même donnée. Rc<T> (reference counted) lève cette limite : il autorise plusieurs propriétaires d'une même valeur, et tient un compteur de ceux-ci. Chaque clone l'incrémente, chaque destruction le décrémente, et la donnée est libérée quand il atteint zéro. La possession unique devient une possession partagée — comptée.Box relocated the data to the heap without touching the golden rule: a single owner. But some structures aren't trees. A graph where two nodes point at the same neighbor; a cache that a service and its logger both consult; data where you can't tell, at compile time, who will free it last. Vol 1's tree can't express it — it would need two parents for one piece of data. Rc<T> (reference counted) lifts that limit: it allows several owners of one value, and keeps a count of them. Each clone increments it, each destruction decrements it, and the data is freed when it reaches zero. Single ownership becomes shared ownership — counted.

use std::rc::Rc;

let donnee = Rc::new(Config { /* ... */ });   // compteur = 1
let a = Rc::clone(&donnee);                    // compteur = 2 — PAS une copie
let b = Rc::clone(&donnee);                    // compteur = 3

// trois propriétaires, une seule donnée sur le tas.
// elle vit tant qu'il reste au moins un Rc ; libérée quand le compteur tombe à 0.
println!("propriétaires : {}", Rc::strong_count(&donnee));  // 3

Rc::clone ne copie pas la donnée — il ajoute un propriétaire.Rc::clone doesn't copy the data — it adds an owner.

Avec la possession unique, confier une donnée à deux structures est impossible : la première la prend par move, la seconde se heurte à un E0382. On pourrait la cloner en profondeur — mais on obtiendrait alors deux copies indépendantes, qui divergeraient à la première modification. Ce n'est pas ce qu'on veut : on veut une seule donnée, vue par deux. Rc le permet, et c'est là qu'est la surprise pour qui débute : Rc::clone porte le mot « clone », mais ne duplique rien. Il incrémente un compteur et te rend un second pointeur vers la même valeur. L'opération est en temps constant, quelle que soit la taille de la donnée — partager un arbre d'un million de nœuds coûte exactement le même incrément que partager un entier.With single ownership, handing one piece of data to two structures is impossible: the first takes it by move, the second hits an E0382. You could deep-clone it — but then you'd get two independent copies, diverging at the first change. That's not what you want: you want one piece of data, seen by two. Rc allows it, and that's where the surprise lies for beginners: Rc::clone carries the word 'clone', but duplicates nothing. It increments a counter and hands you a second pointer to the same value. The operation is constant-time, whatever the data's size — sharing a million-node tree costs exactly the same increment as sharing an integer.

// Possession unique : donner la donnée à l'un, c'est la retirer à l'autre
let arbre = Arbre::new();
let service = Service { arbre };       // arbre est MOVE dans service
let journal = Journal { arbre };       // ✕ error[E0382]: use of moved value
//                       ^^^^^ arbre a déjà été déplacé dans service

// l'arbre ne peut avoir qu'UN propriétaire. impossible de le confier à deux
// structures à la fois — sans le cloner en profondeur (coûteux, et désynchronisé).

Le move du Vol 1 est intraitable : une fois arbre donné à service, il n'existe plus pour journal. La seule échappatoire sans Rc serait un clone profond — recopier tout l'arbre. Mais alors deux arbres distincts existeraient : modifier celui du service ne changerait pas celui du journal. Quand on veut une donnée partagée, pas dupliquée, la possession unique est une impasse.The move from Vol 1 is unyielding: once arbre is given to service, it no longer exists for journal. The only escape without Rc would be a deep clone — recopying the whole tree. But then two distinct trees would exist: changing the service's wouldn't change the logger's. When you want shared data, not duplicated, single ownership is a dead end.

Un bloc de contrôle sur le tas : la valeur, et deux compteurs.A control block on the heap: the value, and two counters.

Derrière Rc, une seule allocation sur le tas regroupe trois choses : la valeur partagée, un compteur « fort » (strong) et un compteur « faible » (weak). Les Rc qui possèdent la donnée comptent dans le strong ; on verra les weak au piège. Chaque Rc::clone incrémente le strong, chaque Rc détruit le décrémente. Lorsque le strong atteint zéro, plus personne ne possède la valeur : son destructeur s'exécute, et la donnée est libérée — une seule fois, déterministe, sans ramasse-miettes. Tout le mécanisme tient dans cet entier partagé. Sa seule subtilité est concurrentielle : si plusieurs threads peuvent cloner et détruire en même temps, l'incrément doit être atomique — et c'est la différence entre Rc et Arc.Behind Rc, a single heap allocation groups three things: the shared value, a 'strong' counter and a 'weak' counter. The Rcs that own the data count in the strong; we'll see the weak in the trap. Each Rc::clone increments the strong, each dropped Rc decrements it. When the strong reaches zero, no one owns the value anymore: its destructor runs, and the data is freed — exactly once, deterministically, with no garbage collector. The whole mechanism fits in that shared integer. Its only subtlety is concurrency: if several threads can clone and drop at once, the increment must be atomic — and that's the difference between Rc and Arc.

let a = Rc::new(String::from("partagé"));   // strong = 1
{
    let b = Rc::clone(&a);                    // strong = 2
    println!("{}", Rc::strong_count(&a));     // 2
}                                             // b sort de portée → strong = 1
println!("{}", Rc::strong_count(&a));         // 1
// quand a disparaîtra à son tour → strong = 0 → la String est libérée, une fois.

use std::rc::Rc;
use std::sync::Arc;

let local = Rc::new(donnee.clone());  // un seul thread — compteur ordinaire, rapide
std::thread::spawn(move || { local });         // ✕ Rc n'est pas Send : ne compile pas

let partage = Arc::new(donnee);        // plusieurs threads — compteur ATOMIQUE
std::thread::spawn({ let p = Arc::clone(&partage); move || { /* p */ } });  // ✓

Deux Rc qui se tiennent l'un l'autre : le compteur ne tombe jamais à zéro.Two Rcs holding each other: the count never falls to zero.

Voici la faille que Rust, exceptionnellement, ne ferme pas. Le comptage de références libère la donnée quand le compteur atteint zéro — mais que se passe-t-il si deux Rc se pointent mutuellement ? A maintient B en vie, B maintient A en vie. Quand toutes les variables externes disparaissent, chacun a encore un compteur à 1, à cause de l'autre. Le compteur n'atteint jamais zéro, le destructeur ne s'exécute jamais, et la mémoire fuit — silencieusement, pour toute la durée du programme. C'est la limite du modèle : la sûreté mémoire de Rust garantit l'absence d'accès invalides, pas l'absence de fuites. Un cycle de Rc est parfaitement « sûr » au sens du compilateur, et pourtant il perd de la mémoire. La sortie a un nom : Weak.Here's the gap that Rust, exceptionally, does not close. Reference counting frees the data when the count reaches zero — but what happens if two Rcs point at each other? A keeps B alive, B keeps A alive. When all external variables vanish, each still has a count of 1, because of the other. The count never reaches zero, the destructor never runs, and memory leaks — silently, for the program's whole life. It's the model's limit: Rust's memory safety guarantees no invalid accesses, not the absence of leaks. A cycle of Rcs is perfectly 'safe' in the compiler's sense, yet it loses memory. The exit has a name: Weak.

// Un parent qui tient ses enfants, et des enfants qui tiennent leur parent — en Rc
struct Noeud {
    parent: RefCell<Option<Rc<Noeud>>>,    // enfant → parent : Rc (fort)
    enfants: RefCell<Vec<Rc<Noeud>>>,      // parent → enfant : Rc (fort)
}

let parent = Rc::new(Noeud { /* ... */ });
let enfant = Rc::new(Noeud { /* ... */ });
parent.enfants.borrow_mut().push(Rc::clone(&enfant));   // parent tient enfant
*enfant.parent.borrow_mut() = Some(Rc::clone(&parent)); // enfant tient parent

// à la fin de portée : strong(parent) = 1, strong(enfant) = 1. JAMAIS 0.
// chacun maintient l'autre en vie → la mémoire FUIT. Rust ne l'empêche pas.

Les deux arêtes sont des Rc forts : parent possède enfant, enfant possède parent. Quand les variables locales sortent de portée, il reste une référence forte de chaque côté — celle que l'autre détient. Les deux compteurs stagnent à 1, aucun n'atteint zéro, et les deux nœuds vivent éternellement sans que personne ne puisse plus les atteindre. C'est une fuite mémoire authentique, dans un langage réputé pour ne pas en avoir.Both edges are strong Rcs: parent owns enfant, enfant owns parent. When the local variables go out of scope, one strong reference remains on each side — the one the other holds. Both counters stall at 1, neither reaches zero, and both nodes live forever while no one can reach them anymore. It's a genuine memory leak, in a language renowned for having none.

// L'arête « retour » devient FAIBLE : Weak ne compte pas dans le strong
struct Noeud {
    parent: RefCell<Weak<Noeud>>,          // enfant → parent : Weak (ne possède pas)
    enfants: RefCell<Vec<Rc<Noeud>>>,      // parent → enfant : Rc (possède)
}

*enfant.parent.borrow_mut() = Rc::downgrade(&parent);  // downgrade : Rc → Weak

// strong(parent) ne compte plus l'enfant. quand parent sort de portée,
// son strong tombe à 0 → libéré → puis l'enfant. plus de cycle, plus de fuite.
let p: Option<Rc<Noeud>> = enfant.parent.borrow().upgrade();  // Weak → Option<Rc>

Weak<T> est une référence qui n'est pas propriétaire : elle pointe la donnée sans compter dans le strong, donc sans l'empêcher de mourir. On garde les liens « possédants » (parent → enfants) en Rc, et les liens « retour » (enfant → parent) en Weak. Le cycle de propriété est brisé : le strong du parent peut atteindre zéro. Pour lire un Weak, on l'upgrade() — qui rend un Option<Rc>, None si la cible a déjà été libérée. L'absence du Vol 3 ressurgit ici : un Weak dit honnêtement « cette cible existe peut-être encore ».Weak<T> is a reference that does not own: it points at the data without counting in the strong, so without preventing its death. You keep the 'owning' links (parent → children) as Rc, and the 'back' links (child → parent) as Weak. The ownership cycle is broken: the parent's strong can reach zero. To read a Weak, you upgrade() it — yielding an Option<Rc>, None if the target was already freed. Vol 3's absence resurfaces here: a Weak honestly says 'this target may still exist'.