Smart Pointers Best Practices

How to Use This List

• Default to references/ownership; escalate to smart pointers with justification.
• Review Arc<Mutex> proliferation in concurrent code.

A - Selection

• Prefer &T / owned T before Rc/Arc. Simpler ownership.
• Use Box for heap single owner or trait objects. Not default for all heap data.
• Rc single-thread only; Arc for threads. Compiler enforces Send where needed.
• RefCell only single-thread interior mutability. Mutex across threads.
• Cow for maybe-mutate borrowed text. Avoid gratuitous String params.

B - Concurrency

• Prefer channels over Arc<Mutex> when possible. Clearer data flow.
• Use atomics for simple counters. Not Mutex<u64> always.
• Do not hold std Mutex guards across .await. Use tokio::sync.
• Handle poisoned mutex explicitly in production. Log and recover policy.
• Document lock ordering if multiple mutexes. Deadlock prevention.

C - Cycles and Memory

• Break Rc cycles with Weak back edges. Trees: parent Weak.
• Avoid long-lived Rc caches without eviction. Memory growth.
• Profile Arc::clone hot paths. Atomic inc cost.
• Use Weak::upgrade handling None. Owner may be gone.
• Consider arena + indices over Rc<RefCell> graphs. Performance.

D - API Design

• Expose &str not Rc<str> unless sharing required. API simplicity.
• Hide RefCell inside type; don't leak guards. Encapsulation.
• Implement Deref not inheritance for newtypes. Transparent access.
• Custom Drop documents safety invariants. Especially FFI.
• Test drop order and RAII with flags in unit tests.

FAQs

Related

• Smart Pointers Basics
• Ownership Best Practices
• Concurrency Best Practices
• Fighting the Borrow Checker

Stack versions: This page was written for Rust 1.97.0 (edition 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, and Polars 0.46+.