Как использовать tokio::sync::RwLock и когда он предпочтительнее Mutex?

Пример: кеш конфигурации

use std::collections::HashMap;
use std::sync::Arc;
use tokio::sync::RwLock;

#[derive(Clone)]
struct ConfigCache {
    inner: Arc<RwLock<HashMap<String, String>>>,
}

impl ConfigCache {
    fn new() -> Self {
        Self {
            inner: Arc::new(RwLock::new(HashMap::new())),
        }
    }

    async fn get(&self, key: &str) -> Option<String> {
        // Много одновременных читателей — ок
        let guard = self.inner.read().await;
        guard.get(key).cloned()
    }

    async fn set(&self, key: String, value: String) {
        // Блокирует всех читателей на время записи
        let mut guard = self.inner.write().await;
        guard.insert(key, value);
    }
}

#[tokio::main]
async fn main() {
    let cache = ConfigCache::new();
    cache.set("db_url".into(), "postgres://...".into()).await;

    let handles: Vec<_> = (0..10)
        .map(|_| {
            let c = cache.clone();
            tokio::spawn(async move {
                let v = c.get("db_url").await;
                println!("{:?}", v);
            })
        })
        .collect();

    for h in handles {
        h.await.unwrap();
    }
}

RwLock против Mutex в Tokio

tokio::sync::RwLock — это читательско-писательская блокировка: одновременно допускается любое количество читателей или один писатель. tokio::sync::Mutex допускает только одного владельца гарда в момент времени, независимо от намерений.

Когда выбирать RwLock

• Данные читаются намного чаще, чем пишутся (кеш конфигурации, справочники).
• Операция чтения занимает заметное время (сериализация, запрос к БД с общим состоянием).
• Нет рекурсивного захвата: писательский гард не запрашивается из кода, уже держащего читательский гард.

Когда оставаться на Mutex

• Записи и чтения примерно одинаковы по частоте — RwLock добавит лишние накладные расходы на учёт счётчика читателей.
• Захваты очень короткие (несколько инструкций) — std::sync::Mutex или даже tokio::sync::Mutex проще и быстрее.
• Нужна строгая очерёдность (FIFO): поведение "writer starvation" у RwLock реализуется по-разному на разных платформах.

Важные детали API

• rw.read().await — возвращает RwLockReadGuard, несколько гардов могут сосуществовать.
• rw.write().await — возвращает RwLockWriteGuard, эксклюзивный доступ.
• rw.try_read() / rw.try_write() — неблокирующие варианты, возвращают TryLockError при неудаче.
• RwLock::with_max_readers(n) — ограничивает максимальное число одновременных читателей (Tokio 1.25+).

Подводные камни

• Writer starvation: если поток читателей непрерывен, писатель будет ждать вечно. Tokio применяет "fair" политику, но при очень высокой нагрузке чтения это всё равно происходит.
• Дедлок читатель→писатель: если задача держит читательский гард и запрашивает писательский (прямо или через канал), возникает взаимная блокировка.
• Долгие гарды через .await: держать гард RwLock через точку .await допустимо, но это блокирует других на всё время ожидания IO — дробите критические секции.
• std::sync::RwLock в async контексте: стандартный RwLock блокирует поток ОС, что может заморозить весь Tokio-воркер; всегда используйте tokio::sync::RwLock.
• Нет рекурсивного захвата: повторный вызов write().await из той же задачи, уже владеющей гардом, — дедлок.
• Накладные расходы счётчика: атомарный счётчик читателей обновляется при каждом захвате — на горячих путях с коротким критическим разделом Mutex окажется быстрее.

• Отвечать определением без production-сценария.
• Не называть runtime boundary, security boundary или failure mode.
• Игнорировать версию API, observability и тестовую проверку.

• Объясняет механизм своими словами и без выдуманных API.
• Называет реальные риски, диагностику и критерий корректности.
• Связывает ответ с текущей документацией и миграционными ограничениями.