Elegir el puntero: Box, Rc, Arc y cómo combinarlos

Ya tienes las cuatro piezas —Box, Rc, Arc, Weak— más la mutabilidad interior de RefCell y Mutex. El arte no está en cada una por separado, sino en elegir. Y elegir es más fácil de lo que parece, porque casi todo se decide con dos preguntas: ¿cuántos dueños necesita este dato? y ¿cuántos hilos lo tocan?. Un dueño y en la pila: nada, ownership normal. Un dueño en el heap: Box. Varios dueños en un hilo: Rc. Varios dueños en varios hilos: Arc. Y si además hay que mutar lo compartido, se añade una segunda capa. Esta lección es el mapa que une el nivel entero.

Dos preguntas, cuatro respuestas

La primera dimensión es la propiedad: cuántos dueños y en cuántos hilos.

flowchart TD
q1{Cuantos duenos} -->|Uno| box_o{En la pila cabe}
box_o -->|Si| pila[Valor normal o referencia]
box_o -->|No: recursivo o dyn o grande| bx[Box de T]
q1 -->|Varios| q2{Cuantos hilos}
q2 -->|Un hilo| rc[Rc de T]
q2 -->|Varios hilos| arc[Arc de T]
style pila fill:#a6e3a1,color:#11111b
style bx fill:#89b4fa,color:#11111b
style rc fill:#cba6f7,color:#11111b
style arc fill:#f9e2af,color:#11111b

La otra dimensión: mutabilidad interior

Rc y Arc solo entregan &T: propiedad compartida es acceso compartido, no mutable. Para mutar lo que compartes hay que componer con mutabilidad interior, y aquí manda una segunda pregunta —de nuevo, cuántos hilos—:

• Rc<RefCell<T>>: compartido y mutable en un hilo. El RefCell traslada las reglas de préstamo a tiempo de ejecución; si las violas, entra en panic! en vez de no compilar.
• Arc<Mutex<T>>: compartido y mutable entre varios hilos. El Mutex garantiza exclusión bloqueando: solo un hilo mantiene el candado a la vez.
• Arc<RwLock<T>>: variante para “muchos lectores o un escritor”, cuando las lecturas dominan.

El orden importa: es Rc<RefCell<T>>, no RefCell<Rc<T>>. La capa exterior dice cómo se comparte la propiedad; la interior, cómo se obtiene la mutación. Compartes la celda, y cada dueño puede pedirle un préstamo mutable.

use std::rc::Rc;
use std::cell::RefCell;

fn main() {
    let compartido = Rc::new(RefCell::new(vec![1, 2, 3]));
    let otro = Rc::clone(&compartido);

    otro.borrow_mut().push(4);                 // muto a traves de un dueno
    println!("{:?}", compartido.borrow());      // [1, 2, 3, 4]: ambos lo ven
}

La tabla de decisión completa

Cruzando las dos dimensiones —propiedad y mutabilidad, un hilo o varios— sale el cuadro que resuelve casi cualquier caso:

Leer el tipo de un dato es, así, leer su contrato: Arc<Mutex<Vec<Cliente>>> te dice sin abrir el código que ese vector es compartido, entre hilos, y mutable bajo candado. La forma anuncia las capacidades.

No sobredimensiones

Cada capa cuesta, y el coste crece por escalones: un valor o una referencia no cuestan nada; Box cuesta una asignación; Rc añade una asignación con contador no atómico; Arc sube a contador atómico; Arc<Mutex<T>> suma además el bloqueo. La regla es alcanzar siempre la herramienta menos potente que resuelva el problema. La mayoría del código no necesita ninguno de estos punteros: le basta con ownership y borrowing. Recurre a Rc<RefCell<T>> para esquivar al borrow checker cuando el diseño lo pide de verdad —un grafo, un observador, un árbol con vuelta atrás—, no como atajo para no pensar la propiedad; ese abuso es un olor a código reconocido, “pelear con el borrow checker a base de comprobaciones en tiempo de ejecución”.