【Rust】17-Send、Sync 与并发安全抽象
Send、Sync 与并发安全抽象
研究目标
- 理解
Send和Sync如何表达跨线程安全。 - 区分所有权转移、共享引用和内部可变性。
- 掌握 Rust 并发抽象背后的类型约束。
Rust 并发安全的基础
Rust 的并发安全不是来自某个单独的锁库，而是所有权、借用和类型系统共同作用的结果。核心原则是：
- 数据可以被移动到另一个线程，但必须安全。
- 数据可以被多个线程共享引用，但共享访问必须安全。
- 可变共享需要同步原语或原子操作。
Send和Sync是两个标记 trait，用于表达这些性质。
Send
Send表示一个类型的值可以安全地转移到另一个线程。
usestd::thread;fnmain(){lettext=String::from("hello");lethandle=thread::spawn(move||{println!("{text}");});handle.join().unwrap();}String是Send，所以可以通过move闭包转移到新线程。
反例是Rc<T>：
usestd::rc::Rc;usestd::thread;fnmain(){letvalue=Rc::new(1);// thread::spawn(move || {// println!("{value}");// });}Rc<T>的引用计数更新不是线程安全的，所以它不是Send。
Sync
Sync表示一个类型可以安全地被多个线程通过共享引用访问。形式化地说，如果&T是Send，那么T是Sync。
i32、String、Vec<T>在合适条件下都是Sync，因为多个线程共享不可变引用读取它们是安全的。
但RefCell<T>不是Sync：
usestd::cell::RefCell;fnmain(){letvalue=RefCell::new(1);*value.borrow_mut()+=1;}RefCell<T>的借用计数是非线程安全的运行时检查，不能被多个线程同时访问。
Arc 与 Mutex
跨线程共享所有权通常使用Arc<T>：
usestd::sync::Arc;usestd::thread;fnmain(){letvalue=Arc::new(String::from("shared"));letcloned=Arc::clone(&value);lethandle=thread::spawn(move||{println!("{cloned}");});println!("{value}");handle.join().unwrap();}如果需要跨线程修改共享数据，使用Mutex<T>：
usestd::sync::{Arc,Mutex};usestd::thread;fnmain(){letcounter=Arc::new(Mutex::new(0));letmuthandles=Vec::new();for_in0..4{letcounter=Arc::clone(&counter);handles.push(thread::spawn(move||{letmutguard=counter.lock().unwrap();*guard+=1;}));}forhandleinhandles{handle.join().unwrap();}println!("{}",*counter.lock().unwrap());}Arc<Mutex<T>>的含义是：多个线程共享同一个所有权句柄，每次修改前先获得互斥锁。
RwLock 与读多写少
RwLock<T>允许多个读者或一个写者：
usestd::sync::RwLock;fnmain(){letvalue=RwLock::new(vec![1,2,3]);{letread=value.read().unwrap();println!("{}",read.len());}{letmutwrite=value.write().unwrap();write.push(4);}}读多写少场景中，RwLock可能比Mutex更合适。但具体性能取决于锁实现、竞争程度和临界区大小。
原子类型
简单计数器可以使用原子类型：
usestd::sync::atomic::{AtomicUsize,Ordering};usestd::sync::Arc;usestd::thread;fnmain(){letcounter=Arc::new(AtomicUsize::new(0));letmuthandles=Vec::new();for_in0..4{letcounter=Arc::clone(&counter);handles.push(thread::spawn(move||{counter.fetch_add(1,Ordering::Relaxed);}));}forhandleinhandles{handle.join().unwrap();}println!("{}",counter.load(Ordering::Relaxed));}原子操作避免锁，但内存序选择很重要。Relaxed只保证原子性，不建立跨线程同步顺序。复杂并发算法应谨慎使用原子并配合测试和模型检查。
Channel
另一种并发思路是消息传递：
usestd::sync::mpsc;usestd::thread;fnmain(){let(tx,rx)=mpsc::channel();thread::spawn(move||{tx.send(String::from("hello")).unwrap();});letmessage=rx.recv().unwrap();println!("{message}");}channel 通过移动消息所有权减少共享状态。很多系统可以优先用消息传递表达工作流，只在必要时共享可变状态。
自动实现与 unsafe impl
Send和Sync通常由编译器自动推导。如果类型的所有字段都是Send，该类型一般也是Send；Sync也类似。
手写unsafe impl Send或unsafe impl Sync意味着你向编译器承诺这个类型满足跨线程安全不变量：
structMyPointer(*mutu8);// unsafe impl Send for MyPointer {}这非常危险。除非你完全理解内部别名、生命周期、同步和释放规则，否则不要手写这些实现。
async 中的 Send
异步任务也常遇到Send：
tokio::spawn(asyncmove{// future 必须 Send + 'static});如果 future 跨.await保存了非 Send 值，整个 future 就不是 Send。解决方式包括改用Arc、缩小非 Send 值作用域、使用本地任务执行器。
常见误解
Arc<T>只提供线程安全引用计数，不让T自动可变。Mutex<T>保护的是数据访问，不是让逻辑自动无死锁。Send是所有权跨线程转移，Sync是共享引用跨线程访问。RefCell<T>是单线程内部可变性，不是线程同步工具。
继续研究
- Rustonomicon：Send and Sync。
- Rust Book：fearless concurrency。
- Rust Reference：marker traits、undefined behavior、data races。
- Loom：并发模型测试工具。
后记
2026年6月11日15点23分于上海。