安全并发不是梦：Rust 并发编程从线程模型到 Tokio 异步实战

原创于 2026-06-22 09:45:05 发布 · 5 阅读

0 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#rust #github #python

安全并发不是梦：Rust 并发编程从线程模型到 Tokio 异步实战

cover

一、并发 Bug 的"薛定谔状态"——Rust 并发安全的价值

并发编程最让人头疼的不是写代码，而是调试。数据竞争导致的 Bug 有三个特征：难以复现、难以定位、难以修复。在 C/C++ 中，一个数据竞争可能表现为"偶尔崩溃"、"偶尔结果不对"或"大部分时间正常但特定负载下出问题"。这种不确定性让调试变成噩梦。

Rust 的并发安全保证不是"帮你写并发代码"，而是"在编译期消灭数据竞争"。通过类型系统（Send/Sync trait）和所有权规则，Rust 保证：如果代码能编译通过，就不存在数据竞争。这是 Rust 并发编程的核心价值——不是让你写得更快，而是让你写得更安全。

但安全不等于简单。Rust 的并发模型包含线程、通道、互斥锁、原子操作、异步运行时等多个层次，每一层都有适用场景和陷阱。这篇文章从底层机制出发，梳理 Rust 并发编程的完整工具链。

二、Rust 并发模型的分层架构

2.1 并发原语全景

graph TB
    A[Rust 并发模型] --> B[OS 线程<br>std::thread]
    A --> C[通道<br>std::sync::mpsc / tokio::sync::mpsc]
    A --> D[共享状态<br>Mutex / RwLock / Atomic]
    A --> E[异步运行时<br>Tokio / async-std]

    B --> F[CPU 密集型任务]
    C --> G[消息传递并发]
    D --> H[共享内存并发]
    E --> I[IO 密集型任务]

    subgraph 编译期安全保证
        J[Send trait: 值可跨线程转移]
        K[Sync trait: 引用可跨线程共享]
    end

    B --> J
    C --> J
    D --> K
    E --> J

    style J fill:#f9f,stroke:#333
    style K fill:#f9f,stroke:#333

2.2 Send 和 Sync：编译期的并发安全守卫

Send 和 Sync 是 Rust 并发安全的基石。它们是 marker trait（没有方法，只作为约束），由编译器自动推导：

Send：一个类型可以安全地跨线程转移所有权。大部分类型自动实现 Send，例外包括 Rc（非线程安全的引用计数）和 RawFd（平台相关的文件描述符）。
Sync：一个类型可以安全地被多个线程同时持有不可变引用。&T 是 Send 当且仅当 T 是 Sync。

use std::thread;
use std::rc::Rc;
use std::sync::Arc;

fn demonstrate_send_sync() {
    // Arc<String> 是 Send + Sync，可以跨线程
    let arc_data = Arc::new(String::from("Hello"));
    let arc_clone = Arc::clone(&arc_data);
    thread::spawn(move || {
        println!("{}", arc_clone); // OK: Arc<String> 是 Send
    });

    // Rc<String> 不是 Send，编译器阻止跨线程
    let rc_data = Rc::new(String::from("World"));
    // let rc_clone = Rc::clone(&rc_data);
    // thread::spawn(move || {
    //     println!("{}", rc_clone); // 编译错误: Rc 不是 Send
    // });
}

2.3 通道：消息传递并发

通道（Channel）是 Rust 推荐的并发模式——"不要通过共享内存来通信，而要通过通信来共享内存"。通道的核心优势是：不需要锁，不需要担心数据竞争，发送方和接收方通过所有权转移来传递数据。

use std::sync::mpsc;
use std::thread;
use std::time::Duration;

fn channel_example() {
    // 创建通道：tx 是发送端，rx 是接收端
    let (tx, rx) = mpsc::channel();

    // 生产者线程——tx 的所有权移动到线程中
    thread::spawn(move || {
        let messages = vec![
            "任务开始",
            "处理数据中...",
            "写入结果",
            "任务完成",
        ];
        for msg in messages {
            tx.send(msg.to_string()).unwrap();
            // send 后 msg 的所有权转移给接收端
            // 发送方无法再访问 msg，保证无数据竞争
            thread::sleep(Duration::from_millis(500));
        }
    });

    // 主线程接收——rx 是迭代器
    for received in rx {
        println!("收到: {}", received);
    }
    // 当发送端 drop 时，rx 迭代结束
}

2.4 Mutex 和 RwLock：共享状态并发

当多个线程需要修改同一份数据时，必须使用互斥锁。Rust 的 Mutex 与 C++ 的 mutex 不同——Rust 的 Mutex 包裹数据，而非独立存在。这意味着你必须先获取锁才能访问数据，编译器保证了这一点。

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

fn mutex_example() {
    // Mutex 包裹数据——必须 lock 才能访问
    let counter = Arc::new(Mutex::new(0));
    let mut handles = vec![];

    for _ in 0..10 {
        let counter_clone = Arc::clone(&counter);
        let handle = thread::spawn(move || {
            // lock() 返回 MutexGuard，实现了 DerefMut
            // 作用域结束时自动释放锁
            let mut num = counter_clone.lock().unwrap();
            *num += 1;
            // num 在这里 drop，锁释放
            // 如果忘记释放锁（比如跨 await 持有），就会死锁
        });
        handles.push(handle);
    }

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

    println!("结果: {}", *counter.lock().unwrap()); // 10
}

三、Tokio 异步运行时实战

3.1 异步 vs 多线程的选型

异步编程和多线程解决的是不同问题：多线程适合 CPU 密集型任务（并行计算），异步适合 IO 密集型任务（网络请求、文件读写）。Tokio 是 Rust 生态中最成熟的异步运行时。

use tokio::time::{sleep, Duration};
use tokio::sync::mpsc;

/// 异步生产者-消费者模式
/// 与 std::sync::mpsc 的区别：
/// 1. tokio::sync::mpsc 的 send/recv 是 async 函数
/// 2. 不会阻塞 OS 线程，适合 IO 密集型场景
/// 3. 支持 bounded channel，背压控制
async fn async_producer_consumer() {
    // 有界通道：容量为 32
    // 当通道满时，send 会等待（背压）
    let (tx, mut rx) = mpsc::channel::<String>(32);

    // 生产者任务
    tokio::spawn(async move {
        for i in 0..100 {
            let msg = format!("消息 {}", i);
            // send 是 async，通道满时等待
            if tx.send(msg).await.is_err() {
                break; // 接收端已关闭
            }
        }
    });

    // 消费者任务
    while let Some(msg) = rx.recv().await {
        println!("处理: {}", msg);
    }
}

3.2 并发任务管理：JoinSet

use tokio::task::JoinSet;

/// 使用 JoinSet 管理多个并发任务
/// 与 vec! + join_all 的区别：
/// JoinSet 支持任务完成时立即处理结果，不需要等所有任务完成
async fn concurrent_requests() -> anyhow::Result<()> {
    let urls = vec![
        "https://httpbin.org/get",
        "https://httpbin.org/ip",
        "https://httpbin.org/headers",
    ];

    let mut tasks = JoinSet::new();
    let client = reqwest::Client::new();

    for url in urls {
        let client = client.clone();
        tasks.spawn(async move {
            let resp = client.get(url).send().await?;
            let body = resp.text().await?;
            anyhow::Ok(body)
        });
    }

    // 逐个处理完成的任务
    while let Some(result) = tasks.join_next().await {
        match result? {
            Ok(body) => println!("响应长度: {}", body.len()),
            Err(e) => eprintln!("请求失败: {}", e),
        }
    }

    Ok(())
}

3.3 超时与取消

use tokio::time::{timeout, Duration};

/// 超时控制：防止任务无限等待
async fn fetch_with_timeout(url: &str) -> anyhow::Result<String> {
    let client = reqwest::Client::new();

    // 5 秒超时
    let result = timeout(
        Duration::from_secs(5),
        client.get(url).send(),
    ).await;

    match result {
        Ok(Ok(resp)) => {
            let body = resp.text().await?;
            Ok(body)
        }
        Ok(Err(e)) => Err(anyhow::anyhow!("请求错误: {}", e)),
        Err(_) => Err(anyhow::anyhow!("请求超时: 5秒")),
    }
}

/// 使用 CancellationToken 实现优雅关闭
use tokio_util::sync::CancellationToken;

async fn long_running_service(token: CancellationToken) {
    loop {
        tokio::select! {
            // 正常工作
            _ = do_work() => {
                if token.is_cancelled() {
                    println!("收到取消信号，正在清理...");
                    break;
                }
            }
            // 等待取消信号
            _ = token.cancelled() => {
                println!("服务被取消，执行清理...");
                break;
            }
        }
    }
}

async fn do_work() {
    sleep(Duration::from_millis(100)).await;
}