Rust RefCell 多线程读为什么也panic了？

非专业程序员2025-11-15 16:58

这是最近实战中遇到的一个小知识点，没理解之前觉得「不可能」，反应过来之后，觉得自己很蠢🤣，借本文记录下。

看一段复现代码：

rust 复制代码

struct MyRefCell<T>(RefCell<T>);

unsafe impl<T> Sync for MyRefCell<T> {}

fn main() {
    let shared = Arc::new(MyRefCell(RefCell::new(0usize)));

    let mut handles = Vec::new();
    for i in 0..100 {
        let s = shared.clone();
        handles.push(thread::spawn(move || {
            thread::sleep(Duration::from_millis(10 * (i % 3) as u64));
            let r = s.0.borrow();
            let r = s.0.borrow_mut();
            println!("thread {} read {}", i, *r);
        }));
    }

    for h in handles {
        let _ = h.join();
    }

    println!("done");
}

多线程读一个RefCell封装的变量，却发生了panic，原因是： **already mutably borrowed: BorrowError**

即 RefCell修饰的变量在borrow时检测到已经borrow_mut了，但是代码里其实没有borrow_mut的地方，就很神奇。

另一个迷惑的地方是，多线程读变量居然也是不安全的，也会panic。

或许有小伙伴不理解RefCell，这里简单介绍下：

Rust的借用检查一般在编译期，即一个可变借用（&mut T）同时只能存在一个，不可变借用（&T）和可变借用不能共存；但在实际场景中，借用关系往往很难在编译期满足，这时候就可以用RefCell，RefCell提供两个操作符：borrow()和borrow_mut()，支持在运行时检查借用关系，如果运行时违法借用规则，会panic。

在我们的代码中，其实没有违反借用规则，因为我们只有不可变借用，但还是panic了，为什么呢？

原因在于RefCell borrow() 的底层实现不是原子的 ，看着是多线程读，其实内部存在写操作，变成了隐藏的多线程写，如下：

可以看出borrow()和borrow_mut()内部实现存在写操作，多线程访问时，flag 状态管理可能出错，导致panic。

同样的问题，在Swift中，如果是多线程读一个变量，是安全的吗？

答案我们将在公众号「非专业程序员Ping」的下一期文章揭晓，欢迎订阅交流！