说实话，第一次接触 RefCell 时，它几乎让我怀疑自己对 Rust 的理解。Rust 的核心承诺是安全与不可变性，怎么会出现一个允许通过不可变引用修改数据的特性呢？这听起来像是违背了语言的设计初衷。
但随着深入了解其在具体场景中的应用，我才意识到 RefCell 的设计精妙之处。它并非规则的破坏者，而是对 Rust 所有权系统的一种必要补充。本文将深入解析 RefCell，并通过一个插件系统的实战案例，展示它与 Rc 如何协同工作。
RefCell是什么？带门禁的可变房间
你可以将 RefCell 想象成一个带有智能门禁的房间。从外部看，这个房间标记为“只读”，任何人都能获得参观许可。但如果你持有特定的门禁权限，进入后你实际上可以重新布置房间内的物品。
这套“门禁系统”就是 RefCell 在运行时所执行的借用检查。让我们通过对比来理解：
正常Rust（编译期检查）：
┌─────────┐ ┌─────────────┐
│ 变量 x │────▶│ 值：10 │ ← 不可变引用 &x
└─────────┘ └─────────────┘
▲
│
想改成20？❌
编译器直接拦住你！
用RefCell（运行时检查）：
┌─────────┐ ┌─────────────────────────┐
│ 变量 x │────▶│ RefCell │ 值：10 │ ← borrow_mut()可以改
└─────────┘ └─────────────────────────┘
▲
│
门禁卡 ✓
运行时检查通过→改成20
在标准的 Rust 中，借用规则由编译器在编译期严格检查：
// 这是行不通的
let x = 10;
let y = &x; // 不可变引用
*y = 20; // 编译器直接报错：不能通过不可变引用修改数据
而 RefCell 将这一检查推迟到了运行时：
use std::cell::RefCell;
fn main() {
let value = RefCell::new(10);
*value.borrow_mut() = 20; // 运行时检查，通过了就能改
println!("Value: {}", value.borrow());
}
这意味着，Rust 会在程序运行时动态监控你对数据的访问，确保没有违反“不可同时存在可变和不可变引用”或“多个可变引用”的规则。如果违规，程序会在运行时 panic，而非在编译时报错。
为什么需要这种东西？
我第一次在构建插件系统时遇到了对 RefCell 的切实需求。系统中各个插件可能相互依赖，形成一个依赖关系图。每个插件都需要能够引用其他插件，同时又要能修改自身的内部状态。
用最直观的方式尝试建模，代码可能长这样：
struct Plugin {
name: String,
dependencies: Vec<&Plugin>, // 引用其他插件
active: bool,
}
编译器会立刻报错，提示“借用值活得不够长”。这正是 Rust 编译期借用检查器的局限性所在——它无法静态地分析和表达“共享所有权且需要内部可变性”这种复杂的运行时关系。
这时，Rc<RefCell<T>> 组合便闪亮登场了。
Rc + RefCell：黄金搭档
Rc 负责在多个所有者间共享数据的所有权，而 RefCell 则提供内部可变性。两者结合，完美解决了上述问题。
先通过一个结构图理解其工作原理：
Rc<RefCell<T>> 的工作原理：
┌──────────────────┐
┌──────│ Rc<T> (引用计数) │──────┐
│ └──────────────────┘ │
│ │
拥有者 A 拥有者 B
│ │
└──────────┬─────────────┬───────┘
▼ ▼
┌──────────────────────────┐
│ RefCell<T> │
│ ┌──────────────────┐ │
│ │ borrow flag │ │ ← 运行时借用检查
│ │ 0=空闲 1=借用 │ │
│ └──────────────────┘ │
│ ┌──────────────────┐ │
│ │ 数据 T │ │
│ └──────────────────┘ │
└──────────────────────────┘
下面是一个完整的插件系统示例代码：
use std::cell::RefCell;
use std::rc::Rc;
// 定义一个类型别名，写起来方便点
type PluginRef = Rc<RefCell<Plugin>>;
struct Plugin {
name: String,
dependencies: Vec<PluginRef>,
active: bool,
}
impl Plugin {
fn new(name: &str) -> PluginRef {
Rc::new(RefCell::new(Self {
name: name.to_string(),
dependencies: Vec::new(),
active: false,
}))
}
fn activate(&mut self) {
self.active = true;
println!("{} 已激活！", self.name);
}
}
现在，你可以轻松地构建插件间的依赖关系：
fn main() {
let plugin_a = Plugin::new("核心模块");
let plugin_b = Plugin::new("用户界面");
// UI插件依赖核心模块
plugin_b.borrow_mut().dependencies.push(plugin_a.clone());
// 激活核心模块
plugin_a.borrow_mut().activate();
// 打印依赖关系
println!(
"{} 依赖 {}",
plugin_b.borrow().name,
plugin_b.borrow().dependencies[0].borrow().name
);
}
对应的依赖关系图如下所示：
插件依赖图：
┌─────────────┐
│ 核心模块 │ ◀───────┐
│ (plugin_a) │ │
└─────────────┘ │
│ │
│ depends │ owns (Rc)
▼ │
┌─────────────┐ │
│ 用户界面 │ ────────┘
│(plugin_b) │
└─────────────┘
Rc让两个插件都能持有对方，
RefCell让它们在需要时能修改内部状态
这段代码能够顺利运行。Rc 使得多个地方可以共享插件的所有权，而 RefCell 则允许这些所有者在必要时安全地修改插件的内部状态。这正是 Rust 中处理共享可变状态的经典模式。
RefCell的借用标志：运行时的守门员
RefCell 内部维护着一个“借用标志”(borrow flag)，它如同一个运行时哨兵，监控着对内部数据的访问。
RefCell内部状态：
┌─────────────────────────────────┐
│ RefCell<T> │
│ │
│ borrow_flag: │
│ ┌─────┬─────┬─────┬─────┐ │
│ │ 0 │ 1 │ 2 │ ... │ │
│ │空闲 │读1 │读2 │读N │ │
│ └─────┴─────┴─────┴─────┘ │
│ │ │
│ │ -1 = 写独占 │
│ │
│ ┌───────────────────────┐ │
│ │ 数据 T │ │
│ └───────────────────────┘ │
└─────────────────────────────────┘
borrow() → flag+1 (读锁)
borrow_mut() → flag=-1 (写锁)
drop() → 恢复原值
当你调用 borrow() 或 borrow_mut() 时，RefCell 会实时检查并更新这个标志：
// 这些操作是安全的
let r1 = refcell.borrow(); // flag: 0 → 1 (开始读)
let r2 = refcell.borrow(); // flag: 1 → 2 (继续读)
drop(r1); // flag: 2 → 1 (结束一个读)
drop(r2); // flag: 1 → 0 (全部结束)
// 这些会panic
let r1 = refcell.borrow(); // flag: 0 → 1 (开始读)
let w1 = refcell.borrow_mut(); // panic! 已经有人在读了
let w1 = refcell.borrow_mut(); // flag: 0 → -1 (开始写)
let w2 = refcell.borrow_mut(); // panic! 已经有人在写
运行时检查的代价是什么？
灵活性并非没有代价。RefCell 的运行时检查会带来一定的性能开销。
以下是不同操作方式的粗略性能对比：
| 操作类型 |
耗时（纳秒） |
相对倍数 |
| 直接修改 |
1.0 |
1倍 |
| RefCell borrow_mut |
13.5 |
约13倍 |
| Rc 修改 |
21.0 |
约21倍 |
用直观的图表展示：
性能对比（纳秒级）：
直接修改: ███ 1.0ns
RefCell: █████████████████████ 13.5ns
Rc+RefCell: █████████████████████████████ 21.0ns
看着差距大，但记住：这是纳秒！
你的代码大部分时间不在这种操作上
数字看起来差距显著，但请记住，这是纳秒级别的差异。在绝大多数实际应用场景中，除非是在极紧密的热点循环中频繁调用，否则这点开销是可以接受的。如果性能真的成为瓶颈，那通常意味着代码的后端 & 架构设计可能需要重新审视，而非单纯是 RefCell 的问题。
此外，使用 RefCell（尤其是结合 Rc）时需要警惕循环依赖。我曾不慎构建了插件A依赖B，同时B又依赖A的循环结构，导致在运行时触发借用错误而 panic：
循环依赖的危险：
┌─────────┐ ┌─────────┐
│ Plugin A│◄────────│ Plugin B│
└─────────┘ └─────────┘
│ │
└───────相互持有─────┘
(Rc<RefCell>)
│
▼
可能导致内存泄漏！
需要用Weak打破循环
这次 panic 也让我明白，RefCell 提供的是受控的灵活性，而非无限制的自由。良好的逻辑设计依然是基础。
RefCell不是打破规则，是完善规则
深入理解 RefCell 后，我认识到它并非在破坏 Rust 的安全规则，而是在完善这套规则体系，使其能够适应更复杂的现实场景。
Rust的安全策略：
编译期检查
┌─────────────────────┐
│ 静态分析 │ ← 大部分情况
│ (借用检查器) │
└─────────────────────┘
│
│ 无法表达？
▼
┌─────────────────────┐
│ 运行时检查 │ ← RefCell/Mutex
│ (动态借用检查) │
└─────────────────────┘
有些程序逻辑的复杂性，是编译期的静态分析无法完全表达的，但运行时的动态检查可以妥善处理。RefCell 正是连接静态安全与动态需求的桥梁。它在维护 Rust 核心安全承诺的前提下，为开发者提供了构建更灵活、动态的软件架构的能力。
可以将借用检查器看作一堵坚固的墙，而 RefCell 则是这堵墙上的一扇安全门。你需要找到正确的“钥匙”（即遵循运行时规则）才能开启，但这扇门的存在，让你能够到达那些原本无法触及的设计领域。
借用检查器这堵墙：
❌ 编译期检查不过
┌─────────────────────────────┐
│ │
│ ╔═══════════════════════╗ │
│ ║ Rust借用检查器 ║ │
│ ║ (墙壁) ║ │
│ ╠═══════════════════════╣ │
│ ║ ║ │
│ ║ [🚪 RefCell] ║ │ ← 后门
│ ║ (运行时检查) ║ │
│ ║ ║ │
│ ╚═══════════════════════╝ │
│ │
└─────────────────────────────┘
│
▼
✅ 运行时通过
总结
RefCell 的核心机制很清晰：它将借用检查从编译期延迟到运行时，从而允许在存在共享所有权的情况下安全地修改内部状态。
使用时请牢记以下几点：
- 运行时检查：违规会导致运行时 panic，而非编译错误。
- 黄金组合：与
Rc (单线程) 或 Arc (多线程) 配合使用，是解决共享可变状态问题的常见模式。
- 性能考量：开销在纳秒级，通常可忽略，但应避免在性能关键的紧密循环中滥用。
- 灵活而非混乱：它赋予的是受控的灵活性，而非编写随意代码的通行证。
Rust 的设计哲学并非将开发者禁锢在狭小的安全区内，而是在保障内存安全的前提下，提供强大的表达能力和灵活性。RefCell 正是这一哲学的具体体现：规则的意义不在于被盲从或打破，而在于被深刻理解并巧妙运用。
希望本文的解析能帮助你更好地掌握 RefCell 这一特性。如果你想了解更多关于 Rust 或其他编程技术的深度讨论，欢迎到技术社区交流，例如 云栈社区 就提供了丰富的技术资源和交流空间。
发表于 7 天前
|
查看: 19|
回复: 0
