深入生产环境的多线程并发编程：Arc与Mutex配合的常见陷阱，Rust里死锁与锁竞争如何有效规避

Wang Liang 2026-09-17 20:53

一、先搞懂两个核心工具：Arc和Mutex到底是啥

很多人刚接触多线程编程时，会觉得这俩词特别玄乎，其实说白了就是生活里的两种常见东西，我先给你用大白话讲透，再结合代码说。

1.1 Arc：共享资源的“拷贝式钥匙”

你可以把Arc想象成一个“共享文件柜的钥匙串”。比如办公室里有个公共文件柜（对应程序里的一块内存资源），大家都要拿里面的资料，总不能把钥匙掰碎了分给每个人吧？那太容易坏了。Arc的做法是：给这个钥匙串做很多份一模一样的拷贝，每个人拿一份，只要还有人拿着钥匙（也就是程序里还有线程在引用这个Arc），文件柜就不会被收走（内存不会被释放）。等所有人都把钥匙还了（所有Arc拷贝都被销毁），文件柜才会被清理。

举个生活的例子：公司的公共笔记本，行政给每个需要用的人发一份带编号的复印件，只要还有人拿着复印件，笔记本就不会被收走，等所有人都用完还回来，行政才会把笔记本收起来。

1.2 Mutex：保护资源的“排队锁”

Mutex更简单，就是公共厕所的门。厕所里的坑位是公共资源，你进去的时候要把门锁上（拿住锁），别人就进不来；你用完出来，把锁打开（释放锁），下一个人才能进去。如果有人进去了不锁门（没拿锁），或者进去了一直不出来（拿锁后不释放），那别人就没法用了。

在程序里，Mutex就是用来保护那些不能同时被多个线程修改的资源，比如你不能同时有两个线程改同一个账户的余额，不然会出现算错钱的问题，Mutex就是防止这种情况的。

二、Arc和Mutex配合的常见陷阱：别让你的程序“卡死”

很多人会把Arc和Mutex配合用，因为既想让多个线程共享同一个资源（用Arc），又想保护这个资源不被乱改（用Mutex），但配合的时候很容易踩坑，我给你说几个最常见的。

2.1 陷阱一：死锁——两个线程互相等对方的锁

死锁就像两个司机在一条窄路上面对面开，谁都不肯让，也退不回去，就这么卡着。在程序里，就是两个线程各自拿了对方需要的锁，都不肯放，导致两个线程都卡死，整个程序也跟着卡。

我给你举个完整的Rust代码例子，技术栈明确是Rust 1.70+，这个例子会模拟两个账户转账的场景，很容易触发死锁：

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

// 定义一个账户结构体，包含账户名和余额
#[derive(Debug)]
struct Account {
    name: String,
    balance: i32,
}

fn main() {
    // 初始化两个账户：A有100元，B有200元
    let account_a = Arc::new(Mutex::new(Account {
        name: "A".to_string(),
        balance: 100,
    }));
    let account_b = Arc::new(Mutex::new(Account {
        name: "B".to_string(),
        balance: 200,
    }));

    // 克隆Arc，传给两个线程
    let a_clone = Arc::clone(&account_a);
    let b_clone = Arc::clone(&account_b);
    let thread1 = thread::spawn(move || {
        // 线程1：A给B转50元，先拿A的锁，再拿B的锁
        let mut a_lock = a_clone.lock().unwrap();
        println!("线程1拿到A的锁，准备转钱");
        // 模拟一些操作，比如检查账户状态，故意加个延迟，让死锁更容易触发
        thread::sleep(std::time::Duration::from_millis(100));
        let mut b_lock = b_clone.lock().unwrap();
        println!("线程1拿到B的锁，开始转钱");

        a_lock.balance -= 50;
        b_lock.balance += 50;
        println!("A转50给B成功，A余额：{}，B余额：{}", a_lock.balance, b_lock.balance);
    });

    let a_clone2 = Arc::clone(&account_a);
    let b_clone2 = Arc::clone(&account_b);
    let thread2 = thread::spawn(move || {
        // 线程2：B给A转30元，先拿B的锁，再拿A的锁
        let mut b_lock = b_clone2.lock().unwrap();
        println!("线程2拿到B的锁，准备转钱");
        // 同样加个延迟
        thread::sleep(std::time::Duration::from_millis(100));
        let mut a_lock = a_clone2.lock().unwrap();
        println!("线程2拿到A的锁，开始转钱");

        b_lock.balance -= 30;
        a_lock.balance += 30;
        println!("B转30给A成功，A余额：{}，B余额：{}", a_lock.balance, b_lock.balance);
    });

    // 等待两个线程结束
    thread1.join().unwrap();
    thread2.join().unwrap();
}

你跑这个代码会发现，程序根本不会结束，两个线程都卡着。为什么？线程1先拿了A的锁，等100毫秒去拿B的锁；线程2先拿了B的锁，等100毫秒去拿A的锁。两个线程都拿着对方需要的锁，谁都不肯放，就这么卡死了，这就是典型的死锁。

2.2 陷阱二：锁竞争——多个线程抢锁抢得太凶

锁竞争就像一群人挤一个厕所，大家都在排队，排的时间太长，整个队伍的进度就慢了。在程序里，如果多个线程频繁抢同一个Mutex的锁，会导致大部分时间都花在排队等锁上，程序的性能会暴跌。

比如你有一个统计网站访问量的计数器，所有请求线程都要去改这个计数器，而这个计数器被一个Mutex保护着。如果网站访问量很大，每秒有几千个请求，那所有请求都要排队等这个锁，每个请求的响应时间就会变得很长，甚至超时。

我给你举个锁竞争的例子，还是Rust代码：

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

fn main() {
    // 初始化一个计数器，初始值为0
    let counter = Arc::new(Mutex::new(0));
    let mut threads = vec![];

    // 记录开始时间
    let start = Instant::now();

    // 创建10个线程，每个线程给计数器加1000次
    for _ in 0..10 {
        let counter_clone = Arc::clone(&counter);
        let thread = thread::spawn(move || {
            for _ in 0..1000 {
                // 每次加1都要拿锁，非常频繁
                let mut lock = counter_clone.lock().unwrap();
                *lock += 1;
            }
        });
        threads.push(thread);
    }

    // 等待所有线程结束
    for thread in threads {
        thread.join().unwrap();
    }

    // 计算总耗时
    let duration = start.elapsed();
    println!("计数器最终值：{}，耗时：{:?}", *counter.lock().unwrap(), duration);
}

你跑这个代码会发现，虽然10个线程每个加1000次，总共加1万次，但耗时会比单线程加1万次慢很多，因为每个线程加1次都要抢锁，大部分时间都在排队等锁。

2.3 陷阱三：锁的范围太大——把不该锁的也锁了

锁的范围太大就像你去厕所，进去后不仅锁了门，还把整个楼层的电源都关了，导致别人没法用电梯、没法开灯，影响了很多不该影响的东西。在程序里，就是你拿了锁之后，执行了很多不需要锁保护的操作，导致锁被占用的时间太长，其他线程等锁的时间也变长了。

比如刚才转账的例子，如果你拿了A的锁之后，先去查A的历史交易记录（这个操作不需要改A的余额，其实不需要锁保护），然后再拿B的锁，那A的锁就被占用了很长时间，其他需要用A的线程就要等更久。

三、死锁和锁竞争的规避方法：让程序又快又稳

针对刚才说的陷阱，我给你说几个实用的解决方法，都是经过生产环境验证的。

3.1 规避死锁：统一锁的获取顺序

刚才死锁的例子，核心问题是两个线程拿锁的顺序不一样：线程1先拿A再拿B，线程2先拿B再拿A。那如果我们规定所有线程拿锁的顺序都一样，比如都先拿编号小的账户，再拿编号大的账户，是不是就不会死锁了？

我们修改刚才的转账代码，把拿锁的顺序统一：

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

#[derive(Debug)]
struct Account {
    name: String,
    balance: i32,
}

fn main() {
    let account_a = Arc::new(Mutex::new(Account {
        name: "A".to_string(),
        balance: 100,
    }));
    let account_b = Arc::new(Mutex::new(Account {
        name: "B".to_string(),
        balance: 200,
    }));

    // 定义一个转账函数，统一拿锁顺序：先拿"名字小"的账户，再拿"名字大"的账户
    fn transfer(from: &Arc<Mutex<Account>>, to: &Arc<Mutex<Account>>, amount: i32) {
        // 先比较两个账户的名字，名字小的先拿锁
        let (first, second) = if from.lock().unwrap().name < to.lock().unwrap().name {
            (from, to)
        } else {
            (to, from)
        };

        // 先拿第一个锁，再拿第二个锁，顺序固定
        let mut first_lock = first.lock().unwrap();
        let mut second_lock = second.lock().unwrap();

        // 处理转账逻辑，注意要判断是从哪个账户转的
        if first_lock.name == "A" && second_lock.name == "B" {
            first_lock.balance -= amount;
            second_lock.balance += amount;
            println!("A转{}给B成功，A余额：{}，B余额：{}", amount, first_lock.balance, second_lock.balance);
        } else {
            second_lock.balance -= amount;
            first_lock.balance += amount;
            println!("B转{}给A成功，A余额：{}，B余额：{}", amount, first_lock.balance, second_lock.balance);
        }
    }

    let a_clone = Arc::clone(&account_a);
    let b_clone = Arc::clone(&account_b);
    let thread1 = thread::spawn(move || {
        transfer(&a_clone, &b_clone, 50);
    });

    let a_clone2 = Arc::clone(&account_a);
    let b_clone2 = Arc::clone(&account_b);
    let thread2 = thread::spawn(move || {
        transfer(&b_clone2, &a_clone2, 30);
    });

    thread1.join().unwrap();
    thread2.join().unwrap();
}

这次跑代码，程序就会正常结束，不会死锁了。因为不管是A转B还是B转A，拿锁的顺序都是先拿A再拿B，两个线程不会互相等对方的锁。

除了统一顺序，还有一个简单的方法：拿锁的时候加超时。如果拿锁超过一定时间还没拿到，就放弃这次操作，避免一直卡着。Rust的Mutex有try_lock方法，不会阻塞，会立刻返回结果，你可以循环尝试几次，每次等一小段时间，还拿不到就放弃。

3.2 规避锁竞争：减少锁的粒度和频率

针对锁竞争的问题，核心思路是让锁被占用的时间尽量短，或者让多个线程不需要抢同一个锁。

第一种方法：减小锁的范围，只在需要保护的操作上拿锁。比如刚才的计数器例子，原来的代码是每次加1都拿锁，其实可以改成每个线程先在自己的本地变量里加，最后再把本地的总和加到全局计数器上，这样就只需要拿一次锁。

修改后的计数器代码：

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

fn main() {
    let counter = Arc::new(Mutex::new(0));
    let mut threads = vec![];
    let start = Instant::now();

    for _ in 0..10 {
        let counter_clone = Arc::clone(&counter);
        let thread = thread::spawn(move || {
            // 本地计数器，不需要锁保护
            let mut local_counter = 0;
            for _ in 0..1000 {
                local_counter += 1;
            }
            // 只有最后加总到全局的时候才拿锁，只拿一次
            let mut lock = counter_clone.lock().unwrap();
            *lock += local_counter;
        });
        threads.push(thread);
    }

    for thread in threads {
        thread.join().unwrap();
    }

    let duration = start.elapsed();
    println!("计数器最终值：{}，耗时：{:?}", *counter.lock().unwrap(), duration);
}

你跑这个代码会发现，耗时比原来的版本短很多，因为每个线程只拿一次锁，锁被占用的时间也很短。

第二种方法：拆分锁，把一个大锁拆成多个小锁。比如你要统计网站的访问量，按地区拆分，每个地区一个计数器，每个计数器一个锁，这样不同地区的请求不会抢同一个锁，锁竞争的概率就小了。

第三种方法：用无锁的数据结构。如果你的场景允许，比如计数器，Rust有原子类型（Atomic），不需要锁就能实现多线程安全的修改，性能比Mutex高很多。比如刚才的计数器，用AtomicI32实现：

use std::sync::atomic::{AtomicI32, Ordering};
use std::thread;
use std::time::Instant;

fn main() {
    // 原子类型，不需要Mutex保护，本身就是线程安全的
    let counter = Arc::new(AtomicI32::new(0));
    let mut threads = vec![];
    let start = Instant::now();

    for _ in 0..10 {
        let counter_clone = Arc::clone(&counter);
        let thread = thread::spawn(move || {
            for _ in 0..1000 {
                // 原子加1，不需要锁
                counter_clone.fetch_add(1, Ordering::SeqCst);
            }
        });
        threads.push(thread);
    }

    for thread in threads {
        thread.join().unwrap();
    }

    let duration = start.elapsed();
    println!("计数器最终值：{}，耗时：{:?}", counter.load(Ordering::SeqCst), duration);
}

这个代码的耗时会更短，因为没有锁的开销，原子操作是CPU层面支持的，速度非常快。

3.3 规避锁范围太大：只在必要时拿锁

针对锁范围太大的问题，核心就是“能不拿锁就不拿锁，拿锁后尽快释放”。比如你拿了锁之后，只做修改资源的操作，其他不需要修改的操作，比如读配置、查历史记录，都放到拿锁之前或者释放锁之后做。

比如转账的例子，你可以先检查两个账户的余额是否足够（这个操作可以用Mutex的try_lock或者先拿锁检查，检查完如果余额不够就立刻释放锁，不需要再拿另一个锁），再进行转账。

四、应用场景、优缺点和注意事项

4.1 应用场景

Arc和Mutex配合的场景主要是多个线程需要共享同一个可变资源，而且这个资源不能被多个线程同时修改的情况。比如：

多个线程共享的数据库连接池，每个线程拿连接的时候要检查连接是否可用，用完要还回去，需要用Mutex保护连接池的状态；
多线程处理任务时，共享的任务队列，每个线程拿任务的时候要修改队列的状态，需要用Mutex保护；
分布式系统中，多个线程共享的配置信息，配置修改的时候需要用Mutex保护，避免多个线程同时修改导致配置不一致。

4.2 技术优缺点

优点：

实现简单，容易理解，不需要复杂的同步机制；
灵活性高，可以保护任意类型的可变资源；
Rust的Arc和Mutex是线程安全的，编译器会帮你检查很多错误，不容易出现内存安全问题。

缺点：

容易出现死锁、锁竞争等问题，性能开销比无锁的方案大；
如果使用不当，会导致程序的性能瓶颈，甚至卡死；
锁的范围如果控制不好，会影响整个程序的并发度。

4.3 注意事项

拿锁后一定要尽快释放，不要在锁里执行耗时的操作，比如网络请求、文件读写等；
尽量减少锁的数量，锁越多，死锁的概率越高；
拿锁的顺序一定要统一，避免死锁；
能不用锁就不用锁，优先用原子类型、无锁数据结构等性能更高的方案；
生产环境中要对多线程程序做压力测试，提前发现死锁和锁竞争的问题。

五、总结

Arc和Mutex是Rust多线程编程中非常常用的组合，既可以实现多个线程共享资源，又可以保护资源不被乱改，但配合的时候很容易踩死锁、锁竞争、锁范围太大这些坑。

规避这些问题的核心思路其实很简单：死锁要靠统一拿锁顺序或者加超时来避免；锁竞争要靠减小锁的粒度、减少拿锁的频率，或者用无锁方案来解决；锁范围太大要靠只在必要时拿锁，拿锁后尽快释放来解决。

不管用什么技术，核心都是理解它的本质，不要为了用而用，要根据场景选择合适的方案。多线程编程不是一蹴而就的，需要不断实践和总结，才能写出又快又稳的生产级程序。

围绕“深入生产环境的多线程并发编程：Arc与Mutex配合的常见陷阱，Rust里死锁与锁竞争如何有效规避”参与讨论

0 条

深入生产环境的多线程并发编程：Arc与Mutex配合的常见陷阱，Rust里死锁与锁竞争如何有效规避

一、先搞懂两个核心工具：Arc和Mutex到底是啥

1.1 Arc：共享资源的“拷贝式钥匙”

1.2 Mutex：保护资源的“排队锁”

二、Arc和Mutex配合的常见陷阱：别让你的程序“卡死”

2.1 陷阱一：死锁——两个线程互相等对方的锁

2.2 陷阱二：锁竞争——多个线程抢锁抢得太凶

2.3 陷阱三：锁的范围太大——把不该锁的也锁了

三、死锁和锁竞争的规避方法：让程序又快又稳

3.1 规避死锁：统一锁的获取顺序

3.2 规避锁竞争：减少锁的粒度和频率

3.3 规避锁范围太大：只在必要时拿锁

四、应用场景、优缺点和注意事项

4.1 应用场景

4.2 技术优缺点

4.3 注意事项

五、总结

评论

关联文章

AI助手

一、先搞懂两个核心工具：Arc和Mutex到底是啥

1.1 Arc：共享资源的“拷贝式钥匙”

1.2 Mutex：保护资源的“排队锁”

二、Arc和Mutex配合的常见陷阱：别让你的程序“卡死”

2.1 陷阱一：死锁——两个线程互相等对方的锁

2.2 陷阱二：锁竞争——多个线程抢锁抢得太凶

2.3 陷阱三：锁的范围太大——把不该锁的也锁了

三、死锁和锁竞争的规避方法：让程序又快又稳

3.1 规避死锁：统一锁的获取顺序

3.2 规避锁竞争：减少锁的粒度和频率

3.3 规避锁范围太大：只在必要时拿锁

四、应用场景、优缺点和注意事项

4.1 应用场景

4.2 技术优缺点

4.3 注意事项

五、总结

同分类面试题

关联文章

AI助手