基于RwLock与HashMap实现Rust线程安全缓存的技术疑问

API 探路者

2026-7-12

Rust线程安全缓存实现的困惑

我尝试用RwLock包裹HashMap实现共享状态的线程安全缓存，希望对外暴露一个单一函数，给定键后返回缓存中对应值的引用（不存在则先填充缓存）。作为中级Rust开发者，我察觉到方案存在几个问题：

问题1：能否返回值的引用？

我知道HashMap必要时会重新分配内存，这会导致引用的生命周期和HashMap不一致，编译器无法确定。HashMap的entry API会返回引用，但该引用无法超出所在作用域。那是不是必须返回具体值，强制值类型实现Copy trait？如果值不实现Copy，情况是否依然如此？

问题2：RwLock读锁升级为写锁的问题

我一开始用的是Mutex，但考虑到缓存的访问模式（每个键写入一次、读取多次），RwLock似乎更合适。但我不确定能不能把读锁升级为读写锁。Rust文档说读锁会阻塞写锁，这会导致我的实现出现死锁。我能不能释放读锁再换成写锁？还是一开始用Mutex更简单？

另外，获取值的函数是异步的，所以虽然能用HashMap::entry API，但没法用Entry的便捷函数（比如or_insert）。

目前的代码实现

// NOTE ：`Key`结构体包含一个生命周期为`'key`的引用
pub struct Cache<'key>(RwLock<HashMap<Key<'key>, Value>>);

impl<'cache, 'key> Cache<'key> {
    pub fn new() -> Arc<Self> {
        Arc::new(Self(RwLock::new(HashMap::new())))
    }

    // NOTE ：缓存的键和值由`Payload`类型派生而来
    pub async fn fetch(
        &'cache mut self,
        data: &'cache Payload<'key>
    ) -> Result<&'cache Value> {
        let cache = self.0.read()?;
        let key = data.into();

        Ok(match &mut cache.entry(key) {
            // 匹配分支类型：&Value
            // FIXME ：该引用超出作用域，存在借用违规
            Entry::Occupied(entry) => entry.get(),

            // 此处存在问题……
            Entry::Vacant(ref mut slot) => {
                // FIXME ：如何在不阻塞现有读锁的情况下创建写锁，避免死锁？

                let value = data.get_value().await?;

                // FIXME ：`VacantEntry<'_, Key<'_>, Value>`未实现`Copy`
                slot.insert(value)
            }
        })
    }
}

问题1的解答

不能直接返回HashMap中值的引用，原因正如你所说：HashMap扩容时会移动元素，原引用会失效，编译器也无法保证引用的生命周期安全。

如果值类型实现Copy，可以返回值的副本，但这不是必须的选择；
如果值不实现Copy，可以考虑返回Arc<Value>：把缓存里的Value用Arc包裹，这样fetch时返回Arc的克隆（代价很低），既避免了引用生命周期问题，也能安全共享。

另外，你的代码里尝试返回&'cache Value是行不通的，因为读锁的生命周期比'cache短，锁释放后引用就悬空了，编译器会直接报错。

问题2的解答

RwLock的读锁无法直接升级为写锁，强行尝试会导致死锁（持有读锁的线程请求写锁，而写锁需要等待所有读锁释放，包括当前线程的）。正确的做法是：

先获取读锁，检查键是否存在：
- 如果存在，返回对应的值（或其Arc克隆）；
- 如果不存在，释放读锁，再获取写锁。
获取写锁后，要再次检查键是否存在（因为在释放读锁到获取写锁的间隙，可能有其他线程已经插入了该键），如果不存在再填充缓存。

异步场景下，不能在持有锁的状态下await（会阻塞executor，破坏异步调度），所以你的代码里在持有读锁时调用data.get_value().await是严重错误——必须先释放所有锁，再执行异步操作。

修正后的代码思路

use std::collections::HashMap;
use std::sync::{Arc, RwLock};

// 假设Key和Value的定义
#[derive(Hash, Eq, PartialEq)]
pub struct Key<'key>(&'key str);
pub struct Value(String);
pub struct Payload<'key>(&'key str);

impl<'key> Payload<'key> {
    pub async fn get_value(&self) -> Result<Value, ()> {
        // 模拟异步获取值
        Ok(Value(self.0.to_string()))
    }
}

impl<'key> From<&Payload<'key>> for Key<'key> {
    fn from(data: &Payload<'key>) -> Self {
        Key(data.0)
    }
}

pub struct Cache<'key>(Arc<RwLock<HashMap<Key<'key>, Arc<Value>>>>);

impl<'key> Cache<'key> {
    pub fn new() -> Arc<Self> {
        Arc::new(Self(Arc::new(RwLock::new(HashMap::new()))))
    }

    pub async fn fetch(&self, data: &Payload<'key>) -> Result<Arc<Value>, ()> {
        let key = data.into();

        // 第一步：读锁检查缓存
        {
            let cache = self.0.read().unwrap();
            if let Some(value) = cache.get(&key) {
                return Ok(value.clone());
            }
        } // 读锁在此处自动释放

        // 第二步：异步获取值
        let value = data.get_value().await?;
        let value_arc = Arc::new(value);

        // 第三步：写锁更新缓存，再次检查避免重复插入
        let mut cache = self.0.write().unwrap();
        match cache.entry(key) {
            std::collections::hash_map::Entry::Occupied(e) => Ok(e.get().clone()),
            std::collections::hash_map::Entry::Vacant(e) => {
                e.insert(value_arc.clone());
                Ok(value_arc)
            }
        }
    }
}

关键优化点

用Arc<Value>存储缓存值，返回Arc克隆，规避引用生命周期问题；
严格遵循“读锁检查→释放读锁→异步操作→写锁更新”的流程，避免持有锁时await；
写锁阶段二次检查键是否存在，防止并发场景下重复填充；
去掉了不必要的'cache生命周期约束，简化代码结构。

内容的提问来源于stack exchange，提问作者Xophmeister

基于RwLock与HashMap实现Rust线程安全缓存的技术疑问

问题1：能否返回值的引用？ #

问题2：RwLock读锁升级为写锁的问题 #

目前的代码实现 #

问题1的解答 #

问题2的解答 #

修正后的代码思路 #

关键优化点 #