Rust's signature achievement is memory safety without a garbage collector. It accomplishes this through a disciplined ownership system — but that system deliberately has an escape hatch: reference counting.

Every value in a Rust program has a single owner at any given time. When that owner goes out of scope, the value is dropped — memory freed, deterministically, at a known point in execution. No GC pause, no dangling pointer, no double-free. The compiler enforces all of this statically.

But some data genuinely needs to be shared: a node in a graph owned by multiple edges, a configuration object threaded through many subsystems, a callback holding a reference into surrounding state. Enter reference counting — Rc<T> and Arc<T> — which shift ownership logic from compile time into a small runtime counter.

These are not competing features. They are complementary tools with distinct trade-offs. This article unpacks both — semantics, performance, ergonomics, and the decisive question: which should you reach for?

The ownership model is Rust's core innovation. Every heap allocation has exactly one owner — the variable binding that "holds" it. Ownership can be moved to another binding, at which point the original is invalidated. It can never be silently copied (unless the type implements Copy).

Move Semantics

fn main() { let s1 = String::from("hello"); let s2 = s1; // ownership MOVED — s1 is now invalid

// println!("{}", s1);  ← compile error: value borrowed after move
println!("{}", s2);  // fine — s2 is the sole owner

} // s2 dropped here, memory freed automatically

The borrow checker enforces the ownership rules. When s1 is assigned to s2, the compiler understands that s1 can no longer be used — it has given up ownership. This eliminates use-after-free at zero runtime cost.

Borrowing — Shared (&T) and Mutable (&mut T)

Moving ownership everywhere would be cumbersome. Rust lets you borrow a value: take a temporary, scoped reference without transferring ownership.

fn calculate_length(s: &String) -> usize { s.len() } // s goes out of scope but does NOT drop the String

fn append_world(s: &mut String) { s.push_str(", world"); }

fn main() { let mut greeting = String::from("hello");

let len = calculate\_length(&greeting); // shared borrow
append\_world(&mut greeting);          // mutable borrow

println!("'{}' has {} characters", greeting, len);

}

The borrow checker enforces two invariants simultaneously:

• Any number of shared (&T) borrows may coexist — they are read-only and cannot alias a mutation.
• Exactly one mutable (&mut T) borrow may exist at a time — and no shared borrows may co-exist with it.

This is aliasing XOR mutability — a fundamental rule that eliminates entire categories of bugs (iterator invalidation, data races) statically.

Lifetimes

References are augmented with lifetimes — annotations that prove a reference cannot outlive the data it points to. In most code the compiler infers them; in complex generic APIs you annotate explicitly.

// 'a says: the returned reference lives at least as long as both inputs fn longest<'a>(x: &'a str, y: &'a str) -> &'a str { if x.len() >= y.len() { x } else { y } }

Key Properties

Ownership & Borrowing is zero-cost: all safety guarantees are verified at compile time and produce no runtime overhead — no counter increments, no heap allocations beyond the value itself, no extra indirection.

Ownership is a strict single-owner model. But some programs require shared ownership — multiple parts of a program that each need to keep a value alive. The classic example is a graph where multiple edges point to the same node.

Rc<T> (Reference Counted) wraps a value on the heap alongside a pair of counters: a strong count (active owners) and a weak count. Every clone of the Rc increments the strong count; every drop decrements it. When the strong count reaches zero, the inner value is dropped.

Basic Usage

use std::rc::Rc;

fn main() { let a = Rc::new(String::from("shared data")); let b = Rc::clone(&a); // increments strong count — cheap pointer clone let c = Rc::clone(&a);

println!("strong count = {}", Rc::strong\_count(&a)); // 3

drop(b);
println!("after drop b = {}", Rc::strong\_count(&a)); // 2

} // a and c drop here; count → 0 → String is freed

Interior Mutability with RefCell

Rc<T> gives shared ownership but immutable access. To mutate the inner value you pair it with RefCell<T>, which moves borrow checking from compile time to runtime:

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

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

let clone1 = Rc::clone(&shared);
let clone2 = Rc::clone(&shared);

clone1.borrow\_mut().push(4);  // runtime borrow check
clone2.borrow\_mut().push(5);

println!("{:?}", shared.borrow()); // \[1, 2, 3, 4, 5\]

}

Thread-Safe Sharing: Arc

Rc<T> is not Send or Sync — its counter is not atomic and cannot cross thread boundaries. For concurrent use, swap in Arc<T> (Atomically Reference Counted), which uses atomic CPU operations for the counter. For interior mutability across threads, pair it with Mutex<T> or RwLock<T>.

use std::sync::{Arc, Mutex}; use std::thread;

fn main() { let counter = Arc::new(Mutex::new(0u32));

let handles: Vec<\_> = (0..8).map(|\_| {
    let c = Arc::clone(&counter);
    thread::spawn(move || {
        \*c.lock().unwrap() += 1;
    })
}).collect();

for h in handles { h.join().unwrap(); }
println!("count = {}", \*counter.lock().unwrap()); // 8

}

Watch Out — Reference Cycles

Rc<T> and Arc<T> cannot automatically detect reference cycles. If two Rc values hold each other, their strong counts never reach zero and you leak memory. Use Weak<T> for back-references (e.g., parent pointers in a tree) to break cycles.

Performance in Practice

The overhead of Rc<T> is three-fold: one extra heap allocation for the control block, one pointer indirection on every access, and two integer increments/decrements on clone and drop. For most programs this is negligible. For hot-path code with millions of operations per second — game engines, compilers, signal processors — preferring owned values matters.

Arc<T> adds further cost: atomic operations use CPU memory-ordering guarantees (SeqCst or Release/Acquire), which inhibit certain compiler and hardware reorderings. On contended multi-core workloads, this can become measurable.

Rule of Thumb

Reach for Rc/Arc when the alternative is fighting the borrow checker with complex lifetime annotations or unsafe code. The small runtime cost buys you ergonomic, safe shared ownership — a reasonable trade in most application code.

Prefer Ownership + Borrowing when…

• Data has a clear single logical owner (most structs, collections, I/O resources).
• You need deterministic, minimal-overhead destruction (RAII for files, sockets, locks).
• You are writing library code where callers should control lifetimes.
• Performance is critical and every allocation counts.

Prefer Rc / Arc when…

• Multiple owners genuinely need to keep the same data alive (graph nodes, parse trees, event listeners).
• The lifetime of data is determined dynamically at runtime, not statically.
• You are bridging with external systems that expect reference semantics (Python extensions, GUI frameworks).
• You want shared state across threads without copying large structures (Arc<Mutex<T>>).

// Classic use case: graph with shared nodes use std::rc::{Rc, Weak}; use std::cell::RefCell;

struct Node { value: i32, children: Vec<Rc<RefCell<Node>>>>, parent: Option<Weak<RefCell<Node>>>>, // Weak breaks parent→child cycle }

impl Node { fn new(value: i32) -> Rc<RefCell<Node>> { Rc::new(RefCell::new(Node { value, children: vec![], parent: None, })) } }