德州北京网站建设站长工具国产

Rust 学习笔记：共享状态并发

消息传递是处理并发性的好方法，但不是唯一的方法。另一种方法是让多个线程访问相同的共享数据。

智能指针使多重所有权成为可能，多重所有权会增加复杂性，因为这些不同的所有者需要管理。Rust 的类型系统和所有权规则极大地帮助了这种管理的正确性。

让我们看看互斥锁，这是共享内存中比较常见的并发原语之一。

互斥锁

互斥只允许一个线程在任何给定的时间访问某些数据。要访问互斥锁中的数据，线程必须首先通过请求获取互斥锁来发出访问信号。lock 是一种数据结构，是互斥锁的一部分，它跟踪当前谁对数据具有独占访问权。

使用互斥锁的两条规则：

1. 在使用数据之前，必须尝试获取锁。
2. 在处理完互斥锁保护的数据后，必须解锁数据，以便其他线程可以获取该锁。

Mutex<T> 的 API

使用 new 函数创建 Mutex<T>。

为了访问互斥体内的数据，我们使用 lock 方法来获取锁。这个调用将阻塞当前线程，因此它不能做任何工作，直到轮到我们获得锁。

如果持有锁的另一个线程 panic，lock 方法将失败。在这种情况下，没有人能够获得锁，所以我们选择了 unwrap，并在这种情况下让线程 panic。

use std::sync::Mutex;fn main() {let m = Mutex::new(5);{let mut num = m.lock().unwrap();*num = 6;}println!("m = {m:?}");
}

在获得锁之后，可以将返回值（在本例中名为 num）作为对内部数据的可变引用。类型系统确保我们在使用 m 中的值之前获得锁。m 的类型是Mutex<i32>，而不是 i32，所以我们必须调用 lock 才能使用 i32 的值。

lock 方法返回一个名为 MutexGuard 的智能指针，封装在调用 unwrap 时处理的 LockResult 中。MutexGuard 智能指针实现了 Deref 和 Drop trait。

当 MutexGuard 超出作用域时自动释放锁，这种情况发生在内部作用域的末尾。因此，我们不会冒忘记释放锁而阻塞互斥锁被其他线程使用的风险，因为锁的释放是自动发生的。

在解除锁之后，我们可以打印互斥锁的值，并看到我们能够将内部的 i32 更改为 6。

在多个线程之间共享互斥锁

现在让我们尝试使用 Mutex<T> 在多个线程之间共享一个值。

启动 10 个线程，并让每个线程将计数器的值增加 1。

use std::sync::Mutex;
use std::thread;fn main() {let counter = Mutex::new(0);let mut handles = vec![];for _ in 0..10 {let handle = thread::spawn(move || {let mut num = counter.lock().unwrap();*num += 1;});handles.push(handle);}for handle in handles {handle.join().unwrap();}println!("Result: {}", *counter.lock().unwrap());
}

编译出错：

错误消息指出计数器值在循环的前一次迭代中被移动。Rust 告诉我们不能将互斥锁的所有权转移到多个线程中。让我们用多重所有权方法来修复错误。

多线程的多重所有权

我们知道使用智能指针 Rc<T> 可以将一个值赋给多个所有者。

修改之前的代码，用 Rc<T> 包装 Mutex<T>，并在将所有权转移到线程之前克隆 Rc<T>。

use std::rc::Rc;
use std::sync::Mutex;
use std::thread;fn main() {let counter = Rc::new(Mutex::new(0));let mut handles = vec![];for _ in 0..10 {let counter = Rc::clone(&counter);let handle = thread::spawn(move || {let mut num = counter.lock().unwrap();*num += 1;});handles.push(handle);}for handle in handles {handle.join().unwrap();}println!("Result: {}", *counter.lock().unwrap());
}

还是编译错误：

Rc<T> 不是线程安全的。当 Rc<T> 管理引用计数时，它将每次克隆调用的计数相加，并在每个克隆被删除时从计数中减去。但是它没有使用任何并发原语来确保计数的更改不会被另一个线程中断。这可能会导致错误的计数，进而导致内存泄漏或在我们完成之前丢弃值。

我们需要的是一种完全类似于 Rc<T> 的类型，但它以线程安全的方式对引用计数进行更改。

Arc<T>：原子引用计数类型

原子引用计数类型 Arc<T> 是一种类似 Rc<T> 的类型，在并发情况下使用是安全的。

原子是一种额外的并发原语，确保线程安全，但线程安全带来了性能损失。

Arc<T> 和 Rc<T> 具有相同的 API，因此我们通过更改 use 行、对 new 的调用和对 clone 的调用来修复程序。

use std::sync::{Arc, Mutex};
use std::thread;fn main() {let counter = Arc::new(Mutex::new(0));let mut handles = vec![];for _ in 0..10 {let counter = Arc::clone(&counter);let handle = thread::spawn(move || {let mut num = counter.lock().unwrap();*num += 1;});handles.push(handle);}for handle in handles {handle.join().unwrap();}println!("Result: {}", *counter.lock().unwrap());
}

程序运行成功，并输出了正确的结果：

注意，如果要进行简单的数值操作，标准库的 std::sync::atomic 模块提供了比 Mutex<T> 更简单的类型。这些类型提供对基本类型的安全、并发的原子访问。

在本例中，我们选择将 Mutex<T> 与基本类型一起使用，这样我们就可以专注于 Mutex<T> 是如何工作的。

RefCell<T>/Rc<T> 与 Mutex<T>/Arc<T> 的相似性

你可能已经注意到 Mutex<T> 提供了内部可变性。

就像我们使用 RefCell<T> 来改变 Rc<T> 中的内容一样，我们使用 Mutex<T> 来改变 Arc<T> 中的内容。

使用 Rc<T> 有创建引用循环的风险，其中两个 Rc<T> 值相互引用，导致内存泄漏。类似地，Mutex<T> 也有创建死锁的风险。当一个操作需要锁定两个资源，并且两个线程各自获得了其中一个锁，导致它们永远等待对方时，就会发生这种情况。