Rust 的 Send 与 Sync 自动推导机制之类型系统如何帮助你写出线程安全的代码_rust

一、分享数据怕出错：多线程编程中最隐蔽的竞态条件

多线程编程的难点不在于"怎么加锁"，而在于"哪里需要加锁"。漏加一把锁，可能在生产环境运行数月才触发一次难以复现的数据竞争。传统语言（c/c++/java）将这个责任完全交给开发者——编译器不会告诉你这个类型能否安全地在线程间传递。

rust 的解决方案是编译期线程安全验证。send 和 sync 两个 trait 在编译期自动推导，确保所有跨线程的数据访问要么是安全的，要么编译器不让你编译通过。不需要运行时检查，不依赖代码审查或测试覆盖。

但自动推导是把双刃剑。理解推导规则的开发者可以写出精妙的零开销线程安全代码。不理解规则的开发者会在尝试跨线程传递看似简单的类型时，被编译器的错误信息淹没。

二、send/sync 的语义定义与自动推导规则

graph td
    a[类型 t] --> b{所有字段都是 send?}
    b -->|是| c[t 自动实现 send]
    b -->|否| d{t 包含裸指针
或 rc?}
    d -->|是| e[t 不实现 send]
    a --> f{所有字段都是 sync?}
    f -->|是| g[t 自动实现 sync]
    f -->|否| h{t 包含内部可变性
且非线程安全?}
    h -->|是| i[t 不实现 sync]
    h -->|否| g
    style c fill:#16213e,stroke:#0f3460,color:#fff
    style g fill:#16213e,stroke:#0f3460,color:#fff
    style e fill:#1a1a2e,stroke:#e94560,color:#ffff
    style i fill:#1a1a2e,stroke:#e94560,color:#ffff

send：所有权可以跨线程转移

send 标记类型 t 的所有权可以安全地从一个线程转移到另一个线程。自动推导规则是：如果类型 t 的所有字段都实现了 send，则 t 自动实现 send。

不自动实现 send 的典型案例：

rc<t>：引用计数使用非原子操作，多线程同时增减会导致计数错误
*const t / *mut t：裸指针无任何线程安全保证
unsafecell<t>：内部可变性的基础原语，本身不提供同步

sync：不可变引用可以跨线程共享

sync 标记 &t 可以安全地在线程间共享（即 t 的不可变引用是 send 的）。自动推导规则与 send 类似。

不自动实现 sync 的常见类型：

cell<t> / refcell<t>：内部可变性无同步保护
mutexguard<t>：持有的锁不应跨线程传递（可能导致死锁）

关键区分

send: t 可以 move 到另一个线程
sync: &t 可以被多个线程同时持有

一个类型可以 send 但不 sync（如 mutex<t>——所有权可以转移，但不能多个线程共享裸引用）。也可以 sync 但不 send（极少见，通常不合法）。

三、编译期线程安全验证的实战案例

use std::rc::rc;
use std::sync::{arc, mutex};
use std::thread;
/// 案例一：rc vs arc —— send 推导差异
/// 
/// 为什么这段代码编译失败：
/// rc 的引用计数用 cell<usize> 实现（非原子操作）
/// cell 不实现 sync，因此 rc 不实现 send
/// 编译器拒绝在 thread::spawn 中捕获 rc
fn rc_cannot_cross_thread() {
    let rc = rc::new(42);
    // 编译错误：`rc<i32>` cannot be sent between threads safely
    // thread::spawn(move || {
    //     println!("{}", rc);
    // });
    // 正确做法：使用 arc（原子引用计数）
    let arc = arc::new(42);
    thread::spawn(move || {
        println!("{}", arc); // arc 实现了 send，编译通过
    });
}
/// 案例二：mutex 是 send 但不是 sync
/// 
/// 这个例子展示了 send 和 sync 的微妙区别
mod case_mutex_send_not_sync {
    use std::sync::mutex;
    use std::thread;
    pub fn demonstrate() {
        let mutex = mutex::new(0);
        // mutex<t> 实现了 send：可以把所有权转移到另一个线程
        // 这对用 mutex 保护跨线程共享数据至关重要
        thread::spawn(move || {
            let mut guard = mutex.lock().unwrap();
            *guard += 1;
        }).join().unwrap();
        // 但是 &mutex<t> 不能随意跨线程共享
        // 因为 mutex 允许通过不可变引用获取可变访问（内部可变性）
        // 编译器需要确保引用传递是安全的
    }
}
/// 案例三：自定义类型 send/sync 推导的精细控制
/// 
/// 使用 phantomdata 标记来手动控制自动推导
use std::marker::phantomdata;
/// 一个包装了 c 库句柄的类型
/// c 库的句柄通常是线程不安全的，但可能在某些条件下安全使用
pub struct foreignhandle {
    raw: *mut std::ffi::c_void,
    /// 为什么用 phantomdata<*const u8>：
    /// *const u8 既不 send 也不 sync
    /// 编译器会阻止自动推导 foreignhandle 的 send/sync
    /// 这比标记 !send 更灵活——可以在确认安全后手动 unsafe impl
    _not_send: phantomdata<*const u8>,
}
// 确认句柄在特定条件下可安全跨线程传递后，
// 手动 unsafe impl send
// 
// 为什么需要 unsafe impl 而非让编译器自动推导：
// 编译器看到 *mut c_void 就会拒绝推导 send
// 但这可能是误报——如果 c 库文档明确声明线程安全
unsafe impl send for foreignhandle {}
/// 案例四：arc<mutex<t>> 的自动推导链
/// 
/// 为什么 arc<mutex<t>> 同时是 send 和 sync（当 t: send 时）：
/// - arc<t>: 当 t: send + sync 时，arc<t> 是 send + sync
/// - mutex<t>: 当 t: send 时，mutex<t> 是 send + sync
/// - 因此 arc<mutex<t>>: 当 t: send 时，同时是 send + sync
/// 
/// 这个组合是 rust 中最常用的线程安全共享模式
fn arc_mutex_auto_derivation() {
    let shared = arc::new(mutex::new(vec![1, 2, 3]));
    let shared_clone = arc::clone(&shared);
    thread::spawn(move || {
        // arc<mutex<vec<i32>>> 实现了 send，可以 move 进闭包
        let mut data = shared_clone.lock().unwrap();
        data.push(4);
    }).join().unwrap();
    // arc<mutex<vec<i32>>> 实现了 sync
    // 可以安全地在多个线程间共享不可变引用
    let guard = shared.lock().unwrap();
    println!("final: {:?}", *guard);
}
/// 案例五：通过 newtype 模式阻断 send 推导
/// 
/// 为什么需要阻断自动推导：
/// 某些类型在语义上不应跨线程，但字段碰巧都是 send 的
/// 如：绑定到特定 os 线程的句柄（信号处理、tls 数据）
pub struct threadbound<t> {
    inner: t,
    /// phantomdata<rc<()>> 阻止 send 推导
    /// 因为 rc<()> 不实现 send
    /// 这不是真正持有 rc，只是借用其 send 否定语义
    _not_send: phantomdata<rc<()>>,
}
impl<t> threadbound<t> {
    pub fn new(inner: t) -> self {
        self { inner, _not_send: phantomdata }
    }
    pub fn get(&self) -> &t {
        &self.inner
    }
}

rust 自动推导的系统性价值

上述案例的核心不在单个技巧，而在整个系统的设计哲学：默认安全，显式 unsafe。编译器自动判断类型的线程安全性，只有确认安全的代码才能编译通过。需要突破编译器限制时，必须显式写 unsafe impl send，这要求开发者对安全性做出明确承诺。

四、自动推导的边界与手动 unsafe impl 的风险

自动推导的局限性：编译器只能检查类型的结构（字段类型），无法理解类型的语义约束。一个所有字段都是 send 的类型，在语义上可能不应跨线程。例如包装了 openssl 上下文指针的类型——虽然 *mut ssl_ctx 从 rust 角度看是 send 的（裸指针标记为 send），但 openssl 内部可能维护线程局部状态。

unsafe impl send 的契约：当使用 unsafe impl send 时，开发者承诺该类型的所有公共 api 在多线程环境中是安全的。这个承诺没有编译器辅助验证——一旦出错，数据竞争就是静默的、难以复现的。

高频误用模式：