Which Rust smart pointer do you actually need?
Box, Rc, Arc, or RefCell? Answer a few quick questions about your ownership situation and get the exact type, with working code using your own type name. No more re-reading the same explainer article for the third time this month.
How SmartPointerPicker works
- 1
It asks about ownership first
The single most important question is whether more than one part of your program needs to own the same value at once. If one owner is enough, you almost never need a reference-counted pointer, and the tool steers you toward Box or a plain value instead.
- 2
Then it asks about threads
If ownership is shared, the next question is whether the value crosses threads. This is what separates Rc (single-threaded, non-atomic counter) from Arc (multi-threaded, atomic counter). Picking wrong here is the most common cause of the "Rc cannot be sent between threads safely" compile error.
- 3
Then it asks about mutation
Rc and Arc only hand out shared references, so if you need to change the value through a shared handle, you need interior mutability. The tool adds RefCell (single-threaded) or Mutex (multi-threaded) to the recommendation exactly when your answer says you need to mutate.
- 4
It substitutes your type name
Type a name in the field at the top and every code snippet updates to use it, so the result is a copy-paste-ready template for your actual struct or enum, not a generic example you have to translate.
- 5
It flags the common mistake for your case
Each recommendation comes with the specific trap people fall into for that choice, such as reaching for Arc in single-threaded code or forgetting the Mutex when you need to mutate through an Arc.
What each smart pointer does
Box<T>
Single ownership on the heap. The one tool that lets a recursive type or trait object have a known size at compile time. No reference counting, no runtime checks, zero overhead beyond the allocation. Reach for it when exactly one thing owns the value.
Reach for it when: Recursive types, trait objects, large values you do not want to move.
Rc<T>
Shared ownership in a single thread. Every Rc::clone bumps a non-atomic counter and gives you another owner; the value drops when the last owner does. Immutable through the handle. Not thread-safe, and the compiler enforces that.
Reach for it when: Tree or graph nodes with multiple parents, single-threaded shared caches.
Arc<T>
Shared ownership across threads. Identical to Rc but with an atomic counter, so clones and drops are safe to interleave between threads. Still immutable through the handle: pair it with Mutex or RwLock to mutate.
Reach for it when: State shared between Tokio tasks or std::thread workers, read-only config.
RefCell<T>
Interior mutability for single-threaded code. Moves Rust's borrow rules from compile time to run time, so you can mutate through a shared reference. A violation (two writers at once) panics rather than failing to compile. Almost always used as Rc<RefCell<T>>.
Reach for it when: Mutating shared single-threaded state, observer patterns, memoized fields.
Mutex<T> / RwLock<T>
Interior mutability for multi-threaded code. Mutex serialises all access behind a lock; RwLock allows many readers or one writer. lock()/write() return a guard that releases the lock when dropped. Almost always used as Arc<Mutex<T>>.
Reach for it when: Mutating shared state across threads, worker pools, shared counters.
Smart pointer syntax reference
The six combinations you will actually reach for, in ascending order of capability and cost.
Box<T> (one owner on the heap)
let boxed: Box<Node> = Box::new(Node::new());
// Recursive types need it to have a known size:
enum List {
Cons(i32, Box<List>),
Nil,
}Rc<T> (many owners, single thread, read-only)
use std::rc::Rc;
let a = Rc::new(Node::new());
let b = Rc::clone(&a); // +1 owner, no copy
println!("{}", Rc::strong_count(&a)); // 2Rc<RefCell<T>> (many owners, single thread, mutable)
use std::rc::Rc;
use std::cell::RefCell;
let a = Rc::new(RefCell::new(Node::new()));
let b = Rc::clone(&a);
a.borrow_mut().update(); // mutate through a shared handle
println!("{:?}", b.borrow());Arc<T> (many owners, many threads, read-only)
use std::sync::Arc;
use std::thread;
let a = Arc::new(Node::new());
let worker = Arc::clone(&a);
thread::spawn(move || worker.read());Arc<Mutex<T>> (many owners, many threads, mutable)
use std::sync::{Arc, Mutex};
let a = Arc::new(Mutex::new(Node::new()));
let worker = Arc::clone(&a);
std::thread::spawn(move || {
worker.lock().unwrap().update(); // lock releases at end of scope
});Arc<RwLock<T>> (read-heavy multi-threaded state)
use std::sync::{Arc, RwLock};
let a = Arc::new(RwLock::new(Node::new()));
let r = a.read().unwrap(); // many readers allowed at once
drop(r);
a.write().unwrap().update(); // one writer, exclusiveWhen to use each type
| Scenario | Reach for | Why |
|---|---|---|
| A recursive enum like a linked list or AST node | Box<T> | Indirection gives the recursive type a known size; one owner per node |
| A tree where child nodes have multiple parents (single-threaded) | Rc<T> | Shared ownership without atomics, nodes freed when the last parent drops |
| A single-threaded graph whose nodes mutate each other | Rc<RefCell<T>> | Shared ownership plus interior mutability, borrow-checked at runtime |
| Read-only config shared across Tokio tasks | Arc<T> | Cheap atomic clones, safe to send between threads, no locking needed |
| A counter or cache mutated by several worker threads | Arc<Mutex<T>> | Thread-safe shared ownership plus one-writer-at-a-time mutation |
| Shared state read constantly but written rarely, across threads | Arc<RwLock<T>> | Many concurrent readers, exclusive writer, better throughput than Mutex |
Frequently Asked Questions
What is the difference between Box, Rc, and Arc in Rust?
All three put a value on the heap, but they differ in how many owners it can have and whether that ownership is safe across threads.
Box<T> is single ownership: exactly one variable owns the value, and it is freed when that owner goes out of scope. Rc<T> (reference counted) allows many owners in a single thread by tracking a non-atomic count. Arc<T> (atomically reference counted) is the thread-safe version of Rc: same many-owner behaviour, but the counter uses atomic operations so it is safe to share across threads.
| Type | Owners | Threads | Extra cost vs Box |
|---|---|---|---|
| Box<T> | One | Move across if T: Send | None |
| Rc<T> | Many | Single thread only | Non-atomic counter |
| Arc<T> | Many | Any thread | Atomic counter |
Can Rc be shared across threads?
No. Rc<T> is not Send or Sync, so the compiler rejects any attempt to move or share it across threads. This is by design: Rc uses a plain, non-atomic integer for its reference count, and if two threads bumped that count at once the count could be corrupted, leading to a use-after-free.
When you need shared ownership across threads, use Arc<T> instead. It is a drop-in replacement with an atomic counter. The only cost is that atomic increments and decrements are slightly slower than the non-atomic ones Rc uses, which is exactly why Rc still exists for single-threaded code.
When should I use RefCell versus Mutex?
| RefCell<T> | Mutex<T> | |
|---|---|---|
| Threading | Single-threaded only | Thread-safe |
| Borrow checking | At runtime, panics on violation | Lock-based, blocks instead |
| Pairs with | Rc<RefCell<T>> | Arc<Mutex<T>> |
| Cost | A borrow flag check | An atomic lock, may block |
Both give you interior mutability (the ability to mutate through a shared reference), but for different contexts. Use RefCell<T> for single-threaded shared state, almost always as Rc<RefCell<T>>. Use Mutex<T> for multi-threaded shared state, almost always as Arc<Mutex<T>>. If your multi-threaded workload is read-heavy, reach for RwLock<T> to allow many concurrent readers.
Does Box implement Clone, and is cloning a Box like cloning an Rc?
Box<T> implements Clone only when the inner T implements Clone, and cloning it performs a deep copy: it allocates a new heap box and clones the value into it. You end up with two independent values.
This is the opposite of Rc::clone and Arc::clone, which do not copy the value at all. They just increment the reference count and hand you another owner of the same underlying value. That is why Rc/Arc clones are cheap and constant-time regardless of how large the value is, while cloning a Box costs as much as copying the whole value.
let a = Box::new(vec![1, 2, 3]);
let b = a.clone(); // deep copy: b is a separate Vec on a new allocation
use std::rc::Rc;
let x = Rc::new(vec![1, 2, 3]);
let y = Rc::clone(&x); // no copy: x and y share one Vec, count is now 2What is the actual performance difference between these types?
Box<T> is the cheapest: one heap allocation and a pointer, with no per-access cost. Rc<T> adds a small non-atomic increment/decrement on clone and drop. Arc<T> does the same but with atomic operations, which are more expensive under contention because CPUs must synchronise cache lines across cores.
RefCell<T> adds a runtime borrow-flag check on every borrow. Mutex<T> adds a lock acquisition that can block the thread entirely if another thread holds the lock. In practice the difference rarely matters until these types sit on a hot path, but the ordering (Box < Rc < Arc, and RefCell < Mutex) is a useful rule of thumb: never pay for thread safety you do not need.
Is my type name or any input sent to a server?
No. SmartPointerPicker is a pure client-side decision tree. Your answers drive a static lookup that returns the matching code template, and your type name is substituted in the browser. Nothing is uploaded, logged, or sent anywhere.