RefCell<T>
和内部可变性模式
内部可变性 是 Rust 中的一种设计模式,它允许你即使在有不可变引用指向数据时也能够改变数据;通常情况下,这种行为是被借用规则所禁止的。为了改变数据,该模式在数据结构内部使用了 unsafe
代码,以绕过 Rust 管理可变性和借用的常用规则。不安全代码向编译器表明,我们正在手动检查规则,而不是依赖编译器为我们检查;我们将在第 20 章中更详细地讨论不安全代码。
只有当我们能够确保即使编译器无法保证,借用规则在运行时也会被遵守时,我们才能使用采用内部可变性模式的类型。然后,所涉及的 unsafe
代码被包装在一个安全的 API 中,而外部类型仍然是不可变的。
让我们通过查看遵循内部可变性模式的 RefCell<T>
类型来探索这个概念。
使用 RefCell<T>
在运行时强制借用规则
与 Rc<T>
不同,RefCell<T>
类型表示对其持有数据的单一所有权。那么,是什么让 RefCell<T>
与像 Box<T>
这样的类型不同呢?回顾一下你在第 4 章学到的借用规则:
- 在任何给定时间,你要么(但不能同时)拥有一个可变引用或任意数量的不可变引用。
- 引用必须始终有效。
对于引用和 Box<T>
,借用规则的不变性在编译时强制执行。对于 RefCell<T>
,这些不变性在运行时强制执行。对于引用,如果你违反这些规则,你将收到编译器错误。对于 RefCell<T>
,如果你违反这些规则,你的程序将 panic 并退出。
在编译时检查借用规则的优点是,错误将在开发过程中更早地被捕获,并且对运行时性能没有影响,因为所有的分析都在事先完成。由于这些原因,在编译时检查借用规则在大多数情况下是最佳选择,这也是 Rust 默认这样做的原因。
在运行时而不是在编译时检查借用规则的优点是,某些内存安全场景是被允许的,而在编译时检查中,它们会被禁止。静态分析,如 Rust 编译器,本质上是保守的。代码的某些属性是不可能通过分析代码来检测的:最著名的例子是停机问题,这超出了本书的范围,但却是一个有趣的研究课题。
由于有些分析是不可能的,如果 Rust 编译器不能确定代码符合所有权规则,它可能会拒绝一个正确的程序;通过这种方式,它是保守的。如果 Rust 接受了一个不正确的程序,用户将无法信任 Rust 所做的保证。然而,如果 Rust 拒绝了一个正确的程序,程序员会感到不便,但不会发生灾难性的事情。当你确信你的代码遵循借用规则,但编译器无法理解和保证这一点时,RefCell<T>
类型就很有用。
与 Rc<T>
类似,RefCell<T>
仅用于单线程场景,如果你尝试在多线程上下文中使用它,将会得到编译时错误。我们将在第 16 章中讨论如何在多线程程序中获得 RefCell<T>
的功能。
以下是选择 Box<T>
、Rc<T>
或 RefCell<T>
的原因回顾:
Rc<T>
允许同一数据的多个所有者;Box<T>
和RefCell<T>
具有单一所有者。Box<T>
允许在编译时检查的不可变或可变借用;Rc<T>
只允许在编译时检查的不可变借用;RefCell<T>
允许在运行时检查的不可变或可变借用。- 由于
RefCell<T>
允许在运行时检查的可变借用,即使RefCell<T>
是不可变的,你也可以改变RefCell<T>
内部的值。
改变不可变值内部的值就是内部可变性模式。让我们看看内部可变性有用的情况,并检查它是如何实现的。
内部可变性:不可变值的可变借用
借用规则的一个结果是,当你有一个不可变值时,你不能可变地借用它。例如,这段代码不会编译:
fn main() {
let x = 5;
let y = &mut x;
}
如果你尝试编译这段代码,你会得到以下错误:
$ cargo run
Compiling borrowing v0.1.0 (file:///projects/borrowing)
error[E0596]: cannot borrow `x` as mutable, as it is not declared as mutable
--> src/main.rs:3:13
|
3 | let y = &mut x;
| ^^^^^^ cannot borrow as mutable
|
help: consider changing this to be mutable
|
2 | let mut x = 5;
| +++
For more information about this error, try `rustc --explain E0596`.
error: could not compile `borrowing` (bin "borrowing") due to 1 previous error
然而,在某些情况下,一个值在其方法中改变自身,但对其他代码表现为不可变值是很有用的。值的方法之外的代码将无法改变该值。使用 RefCell<T>
是获得内部可变性能力的一种方法,但 RefCell<T>
并不能完全绕过借用规则:编译器中的借用检查器允许这种内部可变性,而借用规则则在运行时进行检查。如果你违反了规则,你将得到一个 panic!
而不是编译器错误。
让我们通过一个实际的例子来了解我们可以使用 RefCell<T>
来改变一个不可变的值,并看看为什么这很有用。
内部可变性的用例:Mock 对象
有时在测试期间,程序员会使用一种类型来代替另一种类型,以便观察特定的行为并断言它是否正确实现。这种占位符类型被称为测试替身。把它想象成电影制作中的“特技替身”,一个人介入并代替演员来完成一个特定的棘手场景。当我们运行测试时,测试替身会代替其他类型。Mock 对象是特定类型的测试替身,它记录测试期间发生的事情,以便你可以断言发生了正确的操作。
Rust 没有像其他语言那样的对象概念,Rust 也没有像其他一些语言那样在标准库中内置 mock 对象功能。然而,你绝对可以创建一个 struct,它可以达到与 mock 对象相同的目的。
这是我们将要测试的场景:我们将创建一个库,该库跟踪一个值相对于最大值,并根据当前值与最大值的接近程度发送消息。例如,这个库可以用来跟踪用户允许进行的 API 调用次数的配额。
我们的库将只提供跟踪一个值与最大值的接近程度以及在什么时间应该发送什么消息的功能。使用我们库的应用程序将被期望提供发送消息的机制:应用程序可以将消息放入应用程序中,发送电子邮件,发送短信或其他内容。库不需要知道这个细节。它所需要的只是实现我们将提供的名为 Messenger
的 trait 的东西。列表 15-20 显示了库代码:
pub trait Messenger {
fn send(&self, msg: &str);
}
pub struct LimitTracker<'a, T: Messenger> {
messenger: &'a T,
value: usize,
max: usize,
}
impl<'a, T> LimitTracker<'a, T>
where
T: Messenger,
{
pub fn new(messenger: &'a T, max: usize) -> LimitTracker<'a, T> {
LimitTracker {
messenger,
value: 0,
max,
}
}
pub fn set_value(&mut self, value: usize) {
self.value = value;
let percentage_of_max = self.value as f64 / self.max as f64;
if percentage_of_max >= 1.0 {
self.messenger.send("Error: You are over your quota!");
} else if percentage_of_max >= 0.9 {
self.messenger
.send("Urgent warning: You've used up over 90% of your quota!");
} else if percentage_of_max >= 0.75 {
self.messenger
.send("Warning: You've used up over 75% of your quota!");
}
}
}
这段代码的一个重要部分是 Messenger
trait 有一个名为 send
的方法,该方法接受对 self
的不可变引用和消息文本。这个 trait 是我们的 mock 对象需要实现的接口,以便 mock 对象可以像真实对象一样使用。另一个重要的部分是我们想要测试 LimitTracker
上的 set_value
方法的行为。我们可以改变我们传入的 value
参数,但是 set_value
不返回任何东西供我们进行断言。我们希望能够说,如果我们创建一个 LimitTracker
,它带有实现 Messenger
trait 的东西以及一个特定的 max
值,当我们为 value
传递不同的数字时,消息器会被告知发送适当的消息。
我们需要一个 mock 对象,它不会在调用 send
时发送电子邮件或短信,而只会跟踪它被告知要发送的消息。我们可以创建一个新的 mock 对象实例,创建一个使用 mock 对象的 LimitTracker
,调用 LimitTracker
上的 set_value
方法,然后检查 mock 对象是否具有我们期望的消息。列表 15-21 显示了尝试实现 mock 对象来做到这一点,但借用检查器不允许:
MockMessenger
这段测试代码定义了一个 MockMessenger
struct,它有一个 sent_messages
字段,其中包含 String
值的 Vec
,用于跟踪它被告知要发送的消息。我们还定义了一个关联函数 new
,以便方便地创建新的 MockMessenger
值,这些值以空消息列表开始。然后我们为 MockMessenger
实现 Messenger
trait,以便我们可以将 MockMessenger
提供给 LimitTracker
。在 send
方法的定义中,我们获取作为参数传入的消息,并将其存储在 MockMessenger
的 sent_messages
列表中。
在测试中,我们测试当 LimitTracker
被告知将 value
设置为大于 max
值的 75% 的值时会发生什么。首先,我们创建一个新的 MockMessenger
,它将以空消息列表开始。然后我们创建一个新的 LimitTracker
,并为其提供对新 MockMessenger
的引用和 100 的 max
值。我们使用值 80 调用 LimitTracker
上的 set_value
方法,该值大于 100 的 75%。然后我们断言 MockMessenger
正在跟踪的消息列表现在应该包含一条消息。
然而,这个测试有一个问题,如下所示:
$ cargo test
Compiling limit-tracker v0.1.0 (file:///projects/limit-tracker)
error[E0596]: cannot borrow `self.sent_messages` as mutable, as it is behind a `&` reference
--> src/lib.rs:58:13
|
58 | self.sent_messages.push(String::from(message));
| ^^^^^^^^^^^^^^^^^^ `self` is a `&` reference, so the data it refers to cannot be borrowed as mutable
|
help: consider changing this to be a mutable reference in the `impl` method and the `trait` definition
|
2 ~ fn send(&mut self, msg: &str);
3 | }
...
56 | impl Messenger for MockMessenger {
57 ~ fn send(&mut self, message: &str) {
|
For more information about this error, try `rustc --explain E0596`.
error: could not compile `limit-tracker` (lib test) due to 1 previous error
我们无法修改 MockMessenger
以跟踪消息,因为 send
方法接受对 self
的不可变引用。我们也无法接受错误文本中的建议,即在 impl
方法和 trait
定义中都使用 &mut self
。我们不想仅仅为了测试而更改 Messenger
trait。相反,我们需要找到一种方法,使我们的测试代码在现有设计下正确工作。
这就是内部可变性可以提供帮助的情况!我们将 sent_messages
存储在 RefCell<T>
中,然后 send
方法将能够修改 sent_messages
以存储我们看到的消息。列表 15-22 显示了它的外观:
RefCell<T>
在外部值被认为是不可变的情况下改变内部值sent_messages
字段现在是 RefCell<Vec<String>>
类型,而不是 Vec<String>
。在 new
函数中,我们在空向量周围创建一个新的 RefCell<Vec<String>>
实例。
对于 send
方法的实现,第一个参数仍然是对 self
的不可变借用,这与 trait 定义匹配。我们在 self.sent_messages
上的 RefCell<Vec<String>>
上调用 borrow_mut
,以获取对 RefCell<Vec<String>>
内部值的可变引用,该值是向量。然后我们可以在向量的可变引用上调用 push
,以跟踪在测试期间发送的消息。
我们必须做的最后一个更改是在断言中:要查看内部向量中有多少项,我们在 RefCell<Vec<String>>
上调用 borrow
,以获取对向量的不可变引用。
现在你已经了解了如何使用 RefCell<T>
,让我们深入了解它的工作原理!
使用 RefCell<T>
在运行时跟踪借用
在创建不可变和可变引用时,我们分别使用 &
和 &mut
语法。对于 RefCell<T>
,我们使用 borrow
和 borrow_mut
方法,它们是属于 RefCell<T>
的安全 API 的一部分。borrow
方法返回智能指针类型 Ref<T>
,而 borrow_mut
返回智能指针类型 RefMut<T>
。这两种类型都实现了 Deref
,因此我们可以像对待常规引用一样对待它们。
RefCell<T>
跟踪当前有多少个 Ref<T>
和 RefMut<T>
智能指针处于活动状态。每次我们调用 borrow
时,RefCell<T>
都会增加其活动不可变借用计数的计数。当 Ref<T>
值超出作用域时,不可变借用计数会减少 1。就像编译时借用规则一样,RefCell<T>
允许我们在任何时间点拥有多个不可变借用或一个可变借用。
如果我们尝试违反这些规则,而不是像使用引用那样得到编译器错误,RefCell<T>
的实现将在运行时 panic。列表 15-23 显示了列表 15-22 中 send
实现的修改。我们故意尝试为同一作用域创建两个活动的可变借用,以说明 RefCell<T>
阻止我们在运行时执行此操作。
RefCell<T>
是否会 panic我们为从 borrow_mut
返回的 RefMut<T>
智能指针创建一个变量 one_borrow
。然后我们以相同的方式在变量 two_borrow
中创建另一个可变借用。这在同一作用域中创建了两个可变引用,这是不允许的。当我们为我们的库运行测试时,列表 15-23 中的代码将编译而不会出现任何错误,但测试将失败:
$ cargo test
Compiling limit-tracker v0.1.0 (file:///projects/limit-tracker)
Finished `test` profile [unoptimized + debuginfo] target(s) in 0.91s
Running unittests src/lib.rs (target/debug/deps/limit_tracker-e599811fa246dbde)
running 1 test
test tests::it_sends_an_over_75_percent_warning_message ... FAILED
failures:
---- tests::it_sends_an_over_75_percent_warning_message stdout ----
thread 'tests::it_sends_an_over_75_percent_warning_message' panicked at src/lib.rs:60:53:
already borrowed: BorrowMutError
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
tests::it_sends_an_over_75_percent_warning_message
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
error: test failed, to rerun pass `--lib`
请注意,代码 panic 并显示消息 already borrowed: BorrowMutError
。这就是 RefCell<T>
在运行时处理违反借用规则的方式。
选择在运行时而不是编译时捕获借用错误,正如我们在这里所做的那样,意味着你可能会在开发过程的后期才发现代码中的错误:可能直到你的代码被部署到生产环境。此外,你的代码会因在运行时而不是编译时跟踪借用而产生小的运行时性能损失。然而,使用 RefCell<T>
可以编写一个 mock 对象,该对象可以修改自身以跟踪它看到的消息,而你在只允许不可变值的上下文中使用它。你可以使用 RefCell<T>
,尽管它有权衡,但可以获得比常规引用更多的功能。
通过组合 Rc<T>
和 RefCell<T>
拥有可变数据的多个所有者
RefCell<T>
的常见用法是与 Rc<T>
结合使用。回想一下,Rc<T>
允许你拥有某些数据的多个所有者,但它只提供对该数据的不可变访问。如果你有一个持有 RefCell<T>
的 Rc<T>
,你可以获得一个可以有多个所有者并且你可以改变的值!
例如,回想一下列表 15-18 中的 cons list 示例,我们在其中使用 Rc<T>
来允许多个列表共享对另一个列表的所有权。由于 Rc<T>
仅持有不可变值,因此一旦我们创建了列表,我们就无法更改列表中的任何值。让我们加入 RefCell<T>
以获得更改列表中值的能力。列表 15-24 显示,通过在 Cons
定义中使用 RefCell<T>
,我们可以修改存储在所有列表中的值:
#[derive(Debug)]
enum List {
Cons(Rc<RefCell<i32>>, Rc<List>),
Nil,
}
use crate::List::{Cons, Nil};
use std::cell::RefCell;
use std::rc::Rc;
fn main() {
let value = Rc::new(RefCell::new(5));
let a = Rc::new(Cons(Rc::clone(&value), Rc::new(Nil)));
let b = Cons(Rc::new(RefCell::new(3)), Rc::clone(&a));
let c = Cons(Rc::new(RefCell::new(4)), Rc::clone(&a));
*value.borrow_mut() += 10;
println!("a after = {a:?}");
println!("b after = {b:?}");
println!("c after = {c:?}");
}
Rc<RefCell<i32>>
创建我们可以改变的 List
我们创建一个作为 Rc<RefCell<i32>>
实例的值,并将其存储在名为 value
的变量中,以便稍后我们可以直接访问它。然后我们在 a
中创建一个 List
,其中包含一个持有 value
的 Cons
变体。我们需要克隆 value
,以便 a
和 value
都拥有内部 5
值的所有权,而不是将所有权从 value
转移到 a
或让 a
从 value
借用。
我们将列表 a
包装在 Rc<T>
中,以便当我们创建列表 b
和 c
时,它们都可以引用 a
,这正是我们在列表 15-18 中所做的。
在我们创建了 a
、b
和 c
中的列表之后,我们想要将 10 添加到 value
中的值。我们通过在 value
上调用 borrow_mut
来做到这一点,它使用了我们在第 5 章中讨论的自动解引用功能(参见 “->
运算符在哪里?” 部分)来将 Rc<T>
解引用为内部 RefCell<T>
值。borrow_mut
方法返回一个 RefMut<T>
智能指针,我们对其使用解引用运算符并更改内部值。
当我们打印 a
、b
和 c
时,我们可以看到它们都具有修改后的值 15 而不是 5:
$ cargo run
Compiling cons-list v0.1.0 (file:///projects/cons-list)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.63s
Running `target/debug/cons-list`
a after = Cons(RefCell { value: 15 }, Nil)
b after = Cons(RefCell { value: 3 }, Cons(RefCell { value: 15 }, Nil))
c after = Cons(RefCell { value: 4 }, Cons(RefCell { value: 15 }, Nil))
这项技术非常巧妙!通过使用 RefCell<T>
,我们有一个表面上不可变的 List
值。但是我们可以使用 RefCell<T>
上的方法来提供对其内部可变性的访问,以便我们可以在需要时修改我们的数据。借用规则的运行时检查保护我们免受数据竞争,并且有时值得为了这种数据结构的灵活性而牺牲一点速度。请注意,RefCell<T>
不适用于多线程代码!Mutex<T>
是 RefCell<T>
的线程安全版本,我们将在第 16 章中讨论 Mutex<T>
。