7.3 锁与互斥：Mutex与RwLock

在并发编程中，当多个线程需要同时访问和修改共享数据时，必须确保数据的一致性和完整性。Rust 的类型系统在编译时提供了强大的线程安全保证，而在运行时，我们通常使用锁（Lock） 和互斥（Mutex） 机制来协调对共享资源的访问。本章节将深入探讨 Rust 中两种最常用的同步原语：Mutex 和 RwLock。

7.3.1 什么是互斥锁（Mutex）

Mutex（Mutual Exclusion，互斥）是一种用于保护共享数据的同步原语。它确保在任何时刻，只有一个线程可以访问被保护的数据。当一个线程想要访问数据时，它必须首先“锁定” Mutex。如果另一个线程已经持有锁，当前线程将会阻塞，直到锁被释放。

Rust 标准库中的 std::sync::Mutex 提供了这一功能。它的核心思想是“锁住数据，而不是代码”。Mutex 包裹着需要保护的数据，并通过 lock() 方法返回一个 MutexGuard 智能指针。当 MutexGuard 离开作用域时，锁会自动释放。

基本用法示例：

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

fn main() {
    // 使用 Arc（原子引用计数）来在线程间共享 Mutex
    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 || {
            // 锁定 Mutex，获取内部数据的可变引用
            let mut num = counter.lock().unwrap();
            *num += 1;
        });
        handles.push(handle);
    }

    for handle in handles {
        handle.join().unwrap();
    }

    println!("Result: {}", *counter.lock().unwrap()); // 输出: Result: 10
}

关键点：

  • Arc<Mutex<T>>：Mutex 本身不能在线程间直接移动，因此需要 Arc 来提供多线程共享的所有权。
  • lock() 方法：返回 Result<MutexGuard<T>, PoisonError>。如果锁被其他线程持有，当前线程会阻塞等待。
  • MutexGuard：实现了 Deref 和 DerefMut，可以像普通引用一样使用内部数据。当它被销毁时，锁自动释放。
  • 中毒（Poisoning）：如果线程在持有锁时发生 panic，Mutex 会进入“中毒”状态。后续的 lock() 调用会返回 Err(PoisonError)，以防止数据处于不一致的状态。通常调用 .unwrap() 或 .expect() 来处理，但在生产代码中可能需要更细致的错误恢复策略。

7.3.2 读写锁（RwLock）

RwLock（Read-Write Lock，读写锁）是一种更细粒度的锁。它允许多个线程同时读取数据，但只允许一个线程写入数据。这种机制非常适合“读多写少”的场景，可以显著提高并发性能。

Rust 标准库中的 std::sync::RwLock 提供了这一功能。它提供了两个主要方法：

  • read()：获取一个共享的、只读的锁。多个线程可以同时持有读锁。
  • write()：获取一个独占的、可写的锁。同一时间只能有一个线程持有写锁。

基本用法示例：

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

fn main() {
    let data = Arc::new(RwLock::new(vec![1, 2, 3]));
    let mut handles = vec![];

    // 多个读者线程
    for _ in 0..5 {
        let data = Arc::clone(&data);
        handles.push(thread::spawn(move || {
            let read_guard = data.read().unwrap();
            println!("Read: {:?}", *read_guard);
        }));
    }

    // 一个写者线程
    let data_writer = Arc::clone(&data);
    handles.push(thread::spawn(move || {
        let mut write_guard = data_writer.write().unwrap();
        write_guard.push(4);
        println!("Write: added 4");
    }));

    for handle in handles {
        handle.join().unwrap();
    }

    println!("Final data: {:?}", *data.read().unwrap());
}

关键点：

  • 性能优势：在读多写少的场景下，RwLock 比 Mutex 性能更好，因为它允许多个读者并行执行。
  • 潜在的死锁：如果写锁在等待所有读锁释放，而同时有新的读锁请求不断到来，写锁可能会被“饿死”。Rust 的 RwLock 实现通常会优先考虑写锁，以避免这种情况，但并非所有实现都如此。
  • 使用场景：适用于配置信息、缓存数据、统计信息等频繁读取但偶尔更新的场景。

7.3.3 Mutex vs. RwLock：如何选择

特性Mutex<T>RwLock<T>
并发访问同一时间只有一个线程可以访问（读或写）多个线程可以同时读，但写是独占的
适用场景读写操作频率相当，或写入操作非常频繁读操作远多于写操作
性能开销较低，实现简单较高，需要维护读写状态，可能引入更多上下文切换
死锁风险较低（但依然存在，如忘记释放锁）较高（读锁与写锁之间的相互等待）
API 复杂度简单，只有 lock()稍复杂，有 read() 和 write()

选择建议：

  1. 默认选择 Mutex：如果你不确定哪种锁更适合，或者读写操作频率接近，Mutex 通常是更简单、更安全的选择。
  2. 选择 RwLock 当且仅当：你已经通过性能分析（Profiling）确认 Mutex 是瓶颈，并且数据访问模式是明确的“读多写少”。
  3. 避免过早优化：不要因为“听起来更快”就使用 RwLock。它的实现更复杂，在某些情况下（如写操作频繁）性能可能反而比 Mutex 差。

7.3.4 注意事项与最佳实践

  1. 避免死锁：死锁是锁使用中最常见的问题。例如，线程 A 持有锁 1 并等待锁 2，而线程 B 持有锁 2 并等待锁 1。在 Rust 中，应避免在持有锁的情况下再次尝试获取另一个锁。如果必须使用多个锁，请确保所有线程以相同的顺序获取锁。
  2. 锁的粒度：锁的粒度决定了并发性能。粒度过大（例如用一个锁保护整个大数据结构）会导致线程竞争激烈；粒度过小（例如为每个元素加锁）会增加锁管理的开销和死锁风险。通常，在保证数据一致性的前提下，锁的粒度越小越好。
  3. 使用 Arc 共享：Mutex 和 RwLock 本身是不可复制的，必须通过 Arc（原子引用计数）在多个线程间共享所有权。
  4. 处理中毒：当持有锁的线程 panic 时，锁会中毒。在生产代码中，应避免简单地调用 .unwrap()。可以考虑使用 .lock().unwrap_or_else() 或自定义错误恢复逻辑。
  5. 考虑使用 parking_lot 库：标准库的 Mutex 和 RwLock 是可靠的，但并非性能最优。社区流行的 parking_lot 库提供了更快的实现，且默认不会中毒，在许多高性能应用中更受欢迎。

通过合理使用 Mutex 和 RwLock，你可以安全地管理共享状态，构建高效且正确的并发 Rust 程序。记住，Rust 的所有权和类型系统是防止数据竞争的第一道防线，而锁是解决运行时竞争问题的最后手段。

Last Updated::