Rc de T: propiedad compartida por conteo de referencias

Box impone un dueño único, y casi siempre es lo correcto. Pero algunas estructuras piden que un mismo dato tenga varios dueños: un nodo de un grafo al que apuntan varios padres, una configuración que media docena de componentes comparten, la cola compartida de dos listas. Ahí la propiedad exclusiva estorba. Rc<T> —reference counted, contado por referencias— reparte la propiedad: cada dueño posee una participación, clone no duplica el dato sino que suma uno a un contador, y el valor vive hasta que la última participación se libera. Es propiedad compartida deterministas, sin recolector de basura y sin coste de fondo. El precio: un solo hilo.

Varios dueños para un mismo dato

Con Box no puedes construir dos listas que compartan una misma cola: mover la cola a la primera la deja indisponible para la segunda, y el borrow checker lo rechaza. Rc disuelve el problema dando a cada uno su propia participación sobre el mismo dato:

use std::rc::Rc;

enum Lista {
    Cons(i32, Rc<Lista>),
    Nil,
}
use Lista::{Cons, Nil};

fn main() {
    let compartida = Rc::new(Cons(10, Rc::new(Nil)));
    let a = Cons(3, Rc::clone(&compartida));   // a apunta a la cola compartida
    let b = Cons(4, Rc::clone(&compartida));   // b tambien, sin copiarla
}

Rc::clone(&compartida) no clona en profundidad el Cons(10, ...): fabrica otro Rc que apunta al mismo sitio y suma uno al contador. Es una operación de coste constante, no proporcional al tamaño del dato. La convención de escribir Rc::clone(&x) en vez de x.clone() es deliberada: deja a la vista que es un incremento barato de contador y no una copia costosa.

El conteo de referencias

La mecánica es un contador que sube con cada clone y baja con cada drop; al llegar a cero, el valor y su asignación se liberan. Rc::strong_count te deja observarlo:

use std::rc::Rc;

fn main() {
    let a = Rc::new(String::from("dato"));
    println!("cuenta = {}", Rc::strong_count(&a));   // 1
    let _b = Rc::clone(&a);
    println!("cuenta = {}", Rc::strong_count(&a));   // 2
    {
        let _c = Rc::clone(&a);
        println!("cuenta = {}", Rc::strong_count(&a)); // 3
    } // _c sale de scope: su Drop baja la cuenta a 2
    println!("cuenta = {}", Rc::strong_count(&a));    // 2
} // aqui caen _b y a: la cuenta llega a 0 y la String se libera

No hay que llamar a nada manualmente: el Drop de cada Rc decrementa por ti, y el último en caer ejecuta la destrucción del valor. Es la misma liberación determinista de Box, solo que compartida entre varios puntos del programa que dejan de existir en momentos distintos.

La representación en memoria

Un Rc<T> apunta a una asignación interna —el RcBox— que guarda, contiguos, el contador fuerte, el contador débil (lo verás con Weak) y el valor T. Los contadores viven pegados al dato, en una única asignación; el Rc<T> en sí es una sola palabra: un puntero a esa caja. Por eso todos los clones comparten el mismo contador —apuntan a la misma caja— y por eso clonar es tan barato.

flowchart TB
a[Rc a en pila] --> caja
b[Rc b en pila] --> caja
c[Rc c en pila] --> caja
subgraph caja[RcBox en el heap]
  sc[contador fuerte 3]
  wc[contador debil 0]
  val[valor T]
end
style a fill:#89b4fa,color:#11111b
style b fill:#89b4fa,color:#11111b
style c fill:#89b4fa,color:#11111b
style val fill:#a6e3a1,color:#11111b

Compartido no es mutable

Rc<T> implementa Deref hacia T pero no DerefMut: solo obtienes &T, nunca &mut T. Es forzoso: si varios dueños comparten el dato y cualquiera pudiera pedir &mut, tendrías aliasing mutable —dos referencias mutables vivas al mismo valor— que es exactamente lo que el borrow checker prohíbe. Para mutar un dato compartido necesitas mutabilidad interior: envolver el contenido en un RefCell, dando Rc<RefCell<T>>, que traslada la comprobación de préstamos a tiempo de ejecución. Lo montarás en la última lección del nivel.

Hay una grieta segura: Rc::get_mut devuelve Some(&mut T) solo si la cuenta fuerte es 1 y no hay débiles, es decir, si de hecho no compartes con nadie en ese instante. Si hay más dueños, devuelve None, porque conceder mutabilidad rompería a los demás.

Por qué Rc no cruza hilos

El contador de Rc es un entero normal, incrementado y decrementado sin sincronización. Es rapidísimo, pero frágil ante la concurrencia: si dos hilos clonaran o soltaran el mismo Rc a la vez, las dos operaciones sobre el contador podrían entrelazarse y perder una cuenta, provocando una doble liberación o una fuga. Rust lo impide de raíz: Rc<T> es !Send y !Sync, así que el compilador rechaza moverlo o compartirlo entre hilos. No es una recomendación, es un error de compilación. Para compartir entre hilos existe Arc, la siguiente lección, que paga contadores atómicos a cambio de esa seguridad.