When strong references trap your memory
You're building a file system tree or a UI component hierarchy. A parent node keeps a list of its children. That makes sense. The parent owns the children. But now a child needs to know who its parent is, maybe to navigate up or update state. You add a parent field pointing back to the owner. You run the code. Everything works. Then you drop the root node. The memory doesn't free. Your leak detector screams. The reference counts are stuck at one. You've created a reference cycle.
The cycle keeps itself alive. The parent holds the child. The child holds the parent. Neither can drop because both think the other is still needed. Rust's Rc<T> prevents data races and manages memory, but it cannot solve this logic error on its own. You need a way to say "I want to point to this, but I don't want to keep it alive."
That's what Weak<T> does. It breaks the cycle by providing a non-owning reference.
The lease and the sticky note
Rc<T> keeps a value alive as long as there is at least one strong reference. Every Rc::clone bumps the strong counter. When the counter hits zero, the value drops. A cycle breaks this rule. If Node A holds an Rc to Node B, and Node B holds an Rc to Node A, both counters stay at one forever. Even if you drop everything else, the cycle keeps itself alive.
Think of Rc like a lease on an apartment. As long as someone holds a lease, the apartment stays rented. If Alice leases Bob's apartment and Bob leases Alice's apartment, both apartments stay occupied even if they move out, because they're holding each other's leases.
Weak<T> is like a sticky note on the door. It says "Bob lives here," but it doesn't count as a lease. If Bob moves out, the sticky note just points to an empty room. The apartment can finally be cleared. The sticky note doesn't prevent the cleanup. It just observes the state.
Breaking the cycle with code
You use Weak<T> for back-references. The child holds a Weak to the parent. The parent holds an Rc to the child. The parent owns the child. The child observes the parent. When the parent drops, the child's weak pointer becomes invalid, and the child can drop normally.
use std::cell::RefCell;
use std::rc::{Rc, Weak};
#[derive(Debug)]
struct Node {
value: i32,
// Weak doesn't own the parent. It can't prevent the parent from dropping.
parent: RefCell<Weak<Node>>,
// Children are owned strongly. The parent keeps them alive.
children: RefCell<Vec<Rc<Node>>>,
}
fn main() {
let child = Rc::new(Node {
value: 1,
parent: RefCell::new(Weak::new()),
children: RefCell::new(vec![]),
});
let parent = Rc::new(Node {
value: 2,
parent: RefCell::new(Weak::new()),
// Clone the Rc to add to children. This bumps the strong count.
children: RefCell::new(vec![Rc::clone(&child)]),
});
// Downgrade the parent Rc to a Weak pointer.
// This does NOT bump the strong count.
*child.parent.borrow_mut() = Rc::downgrade(&parent);
// Upgrade checks if the parent is still alive.
if let Some(parent_ref) = child.parent.borrow().upgrade() {
println!("Child's parent value: {}", parent_ref.value);
} else {
println!("Parent is gone.");
}
}
The RefCell here allows you to mutate the weak pointer after the struct is created. You create the child, create the parent, then link them. Without RefCell, the parent field would be immutable once the Node is constructed. Convention in Rust is to wrap Weak in RefCell when the back-reference needs to be set or updated after allocation.
How Weak actually works
Weak<T> tracks the same heap allocation as the Rc, but it maintains a separate weak count. When you call Rc::downgrade, you get a Weak that increments the weak count but leaves the strong count untouched.
The lifecycle has two phases. First, when the strong count drops to zero, the inner value is dropped. At this point, the data is gone. Any Weak pointer still exists, but upgrade will return None. The memory for the value is freed, but the control block remains alive because the weak count is still positive.
Second, when the weak count also drops to zero, the control block is freed. This two-phase drop ensures safety. If a strong reference is dropped while a weak reference is trying to upgrade, the weak pointer can still check the control block to see that the value is gone. It never accesses freed memory.
Weak::upgrade returns Option<Rc<T>>. You must handle the None case. The target might have been dropped. This is not a bug. It's the feature. The weak pointer admits when the data is no longer available.
Why Weak and RefCell are best friends
You'll often see RefCell<Weak<T>> together. There are two reasons. First, you usually need to set the weak pointer after both objects exist. You create the child, create the parent, then link them. RefCell provides interior mutability.
Second, if you have a graph where nodes can be reparented, you need to update the weak pointer. RefCell lets you do that safely at runtime. The borrow checker catches logic errors where you try to read and write the parent pointer at the same time.
Convention aside: use Weak::new() for initialization. It creates a null weak pointer. Use Rc::downgrade to create a valid weak pointer from an existing Rc. Don't try to construct a Weak from scratch without an Rc. The API doesn't allow it. You can't point to a random address.
Realistic example: finding the root
A common pattern is walking up a tree to find the root. You start at a leaf and follow weak parent pointers until you hit None.
use std::cell::RefCell;
use std::rc::{Rc, Weak};
#[derive(Debug)]
struct TreeNode {
label: String,
parent: RefCell<Weak<TreeNode>>,
children: RefCell<Vec<Rc<TreeNode>>>,
}
impl TreeNode {
/// Create a new tree node wrapped in Rc.
fn new(label: &str) -> Rc<Self> {
Rc::new(TreeNode {
label: label.to_string(),
parent: RefCell::new(Weak::new()),
children: RefCell::new(vec![]),
})
}
/// Add a child and set its parent weak reference.
fn add_child(&self, child: Rc<TreeNode>) {
// Downgrade self to a weak pointer for the child.
*child.parent.borrow_mut() = Rc::downgrade(self);
self.children.borrow_mut().push(child);
}
/// Walk up the tree to find the root node.
fn get_root(&self) -> Option<Rc<TreeNode>> {
let mut current = Rc::clone(self);
loop {
// Try to upgrade the weak parent pointer.
let parent_opt = current.parent.borrow().upgrade();
match parent_opt {
Some(parent) => current = parent,
None => return Some(current),
}
}
}
}
fn main() {
let root = TreeNode::new("Root");
let child = TreeNode::new("Child");
root.add_child(child);
// Find the root from the child.
if let Some(found_root) = child.get_root() {
println!("Found root: {}", found_root.label);
}
}
The get_root method walks up the chain. Each step upgrades a weak pointer. If the parent is still alive, the loop continues. If the parent is gone, the loop stops and returns the current node as the effective root. This handles cases where the tree is partially dropped or reparented.
Always handle the None from upgrade. A weak pointer is a promise that the data might vanish. Your code must be ready for that.
Pitfalls and compiler errors
If you try to assign a Weak to an Rc field, the compiler rejects it with E0308 (mismatched types). Weak and Rc are distinct types. You can't accidentally create a cycle by assigning the wrong pointer type. The type system forces you to choose.
If you hold a borrow on the parent while trying to upgrade, you might hit E0502 (cannot borrow as mutable because it is also borrowed as immutable). Be careful with RefCell borrows. Drop the borrow before calling upgrade if you need to mutate something else.
A common mistake is using Weak where you need ownership. Weak doesn't keep data alive. If you store a Weak in a cache and nothing else holds the data, the data drops immediately. The cache becomes useless. Use Weak only when something else owns the data, or when you explicitly want the data to be optional and droppable.
Another pitfall is forgetting that Weak requires RefCell for mutation in many cases. If you store Weak<T> directly in a struct behind an Rc, you can't change the weak pointer after creation. You'll need RefCell or you'll need to design the struct so the weak pointer is set once and never changes.
Weak pointers are not magic. They are a contract. You promise not to keep the data alive. If you break that contract, you get a cycle.
Weak for caches and observers
Weak shines in caches. Imagine a global cache of parsed documents. You store Weak<Document> in the cache. If the document is still alive elsewhere, the cache can return it. If the document was dropped, the cache entry returns None and can be cleaned up. This prevents the cache from holding the entire application's data hostage.
Use Weak when you want to observe an object without preventing cleanup. Use it for back-references in graphs. Use it for optional relationships where the target might disappear.
Decision: when to use Weak vs alternatives
Use Rc<T> when multiple parts of your code need to read the same data and you want the data to stay alive as long as anyone holds a reference. Use Weak<T> when you need a back-reference in a graph or tree structure to break a cycle that would otherwise prevent memory from being freed. Use Weak<T> when you want to cache a reference or observe an object without preventing it from being dropped. Use Option<Rc<T>> when the relationship is optional but you still want to keep the target alive if the reference exists. Reach for Weak only when you have a cycle or a non-owning observation pattern; otherwise, prefer strong references to keep the ownership graph simple.
Trust the borrow checker. It usually has a point. If you're fighting cycles, Weak is the tool. If you're not fighting cycles, you probably don't need Weak.