引言

你是否遇到過 Rust 併發場景下的資源競爭、性能瓶頸？
當多個線程同時抓取網頁導致 IP 被封、多線程讀寫本地數據引發一致性問題時，如何優雅地實現線程安全？

本文結合開源項目 Saga Reader 的真實開發場景，深度解析 Arc/Mutex/RwLock 的實戰技巧，帶你從 “踩坑” 到 “優化”，掌握 Rust 併發編程的核心方法論，文末附項目地址，歡迎 star 交流！
關於開源項目Saga Reader（中文麒睿智庫），之前我在博客園中有詳細介紹，新朋友可以先閲讀這篇文章。

技術背景

在 Rust 編程的世界裏，併發編程是一個既強大又充滿挑戰的領域。為了實現高效、安全的併發操作，Rust 提供了一系列實用的工具，其中 Arc（原子引用計數指針）和 Mutex（互斥鎖）、RwLock（讀寫鎖）是非常關鍵的組件。本文將結合 Saga Reader 項目中的實際應用案例，深入探討 Arc、Mutex、RwLock 的使用場景、技術要點，並結合我們的 Saga Reader 項目中的實際案例，分享它們在併發場景下的使用技巧和設計哲學。

什麼是Saga Reader

基於Tauri開發的開源AI驅動的智庫式閲讀器（前端部分使用Web框架），能根據用户指定的主題和偏好關鍵詞自動從互聯網上檢索信息。它使用雲端或本地大型模型進行總結和提供指導，幷包括一個AI驅動的互動閲讀伴讀功能，你可以與AI討論和交換閲讀內容的想法。

這個項目我5月剛放到Github上（Github - Saga Reader），歡迎大家關注分享。🧑‍💻碼農🧑‍💻開源不易，各位好人路過請給個小星星💗Star💗。

核心技術棧：Rust + Tauri（跨平台）+ Svelte（前端）+ LLM（大語言模型集成），支持本地 / 雲端雙模式

關鍵詞：端智能，邊緣大模型；Tauri 2.0；桌面端安裝包 < 5MB，內存佔用 < 20MB。

運行截圖

項目核心模塊

問題初現：無 Arc 與 Mutex 的困境

因為是本地桌面端，涉及到本地數據的併發讀寫以及數據抓取的併發限流控制。以網頁內容抓取模塊為例，多個線程同時進行網頁抓取操作，代碼如下：

// 早期網頁抓取示例
use reqwest;

async fn scrap_text_by_url(url: &str) -> anyhow::Result<String> {
    let response = reqwest::get(url).await?;
    let text = response.text().await?;
    // 處理網頁內容
    Ok(text)
}

由於沒有任何同步機制，多個線程可能會同時訪問同一個網頁資源，服務器可能會將這些請求視為惡意攻擊，從而對 IP 進行封禁。同時，多個線程同時處理抓取到的內容，可能會導致數據處理混亂，影響最終結果的準確性。

再比如對本地數據的讀取，無併發控制會引起數據不一致問題。

引入 Arc 與 Mutex：柳暗花明

Arc

Arc 是 Rust 標準庫中的一個智能指針，全稱為 Atomic Reference Counting。在多線程環境中，多個線程可能需要同時訪問同一個資源，Arc 可以讓多個線程安全地共享同一個數據實例。它通過原子操作來管理引用計數，當引用計數降為 0 時，數據會被自動釋放，從而避免了數據競爭和內存泄漏的問題。

Mutex

Mutex 即互斥鎖，是一種用於實現線程同步的機制。在多線程編程中，多個線程可能會同時訪問和修改共享資源，這可能會導致數據不一致或其他競態條件。Mutex 可以確保在同一時間只有一個線程能夠訪問被保護的資源，從而保證數據的一致性和線程安全。

Saga Reader 中的 Mutex 實戰

源碼：scrap/src/simulator.rs

在 Saga Reader 項目中，我們有一個模擬瀏覽器行為來抓取網頁內容的功能，位於 。由於創建和管理模擬的 Webview 窗口是資源密集型操作，並且可能涉及到一些全局狀態或限制（例如，不能同時打開多個同名的模擬窗口），我們需要確保這部分操作的串行化執行。

為什麼選擇 Mutex 而非其他鎖？
> 模擬 Webview 窗口創建是資源密集型操作，且需保證同一時刻僅允許一個實例運行（避免內存泄漏和窗口句柄衝突）。此時寫操作（創建窗口）是核心操作，讀操作極少，因此選擇 Mutex 保證獨佔性，而非引入 RwLock 的複雜度。

// ... existing code ...
use tokio::sync::{oneshot, Mutex}; // 引入 Tokio 的異步 Mutex
// ... existing code ...

// 使用 once_cell 的 Lazy 來延遲初始化一個全局的、帶 Arc 的 Mutex
// Arc<Mutex<()>> 中的 () 表示我們用這個 Mutex 保護的不是具體數據，
// 而是保護一段代碼邏輯的獨佔執行權。
static MUTEX: Lazy<Arc<Mutex<()>>> = Lazy::new(|| Arc::new(Mutex::new(())));

pub async fn scrap_text_by_url<R: Runtime>(
    app_handle: AppHandle<R>,
    url: &str,
) -> anyhow::Result<String> {
    // 在關鍵代碼段開始前，異步獲取鎖
    // _lock 是一個 RAII 守護（guard），當它離開作用域時，鎖會自動釋放
    let _lock = MUTEX.lock().await;
    match app_handle.get_webview_window(WINDOW_SCRAP_HOST) {
        Some(_) => {
            error!("The scrap host for simulator was busy to use, scrap pages at the same time was not support currently!");
            Err(anyhow::anyhow!("Scrap host is busy"))
        }
        None => {
            // ... 創建和操作 Webview 窗口的代碼 ...
            // 這部分代碼在持有鎖的期間執行，保證了同一時間只有一個任務能執行到這裏
            let window = WebviewWindowBuilder::new(
// ... existing code ...
            Ok(result)
        }
    }
    // _lock 在這裏離開作用域，Mutex 自動釋放
}

在這個例子中，static MUTEX: Lazy<Arc<Mutex<()>>> 定義了一個全局靜態的互斥鎖。Arc 使得這個 Mutex 可以在多個異步任務之間安全共享。Lazy 確保 Mutex 只在第一次被訪問時初始化。Mutex<()> 表示這個鎖並不直接保護某個具體的數據，而是用來控制對一段代碼邏輯（即創建和使用 WINDOW_SCRAP_HOST 窗口的過程）的獨佔訪問。通過 MUTEX.lock().await，任何嘗試執行 scrap_text_by_url 的任務都必須先獲得這個鎖，從而保證了模擬器資源的串行使用，避免了潛在的衝突和錯誤。

讀多寫少場景的性能利器：RwLock

雖然 Mutex 提供了強大的數據保護能力，但它的獨佔性在某些場景下可能會成為性能瓶頸。想象一個場景：我們有一個共享的配置對象，它很少被修改（寫操作），但會被非常頻繁地讀取（讀操作）。如果使用 Mutex，即使是多個讀操作也不得不排隊等待，這顯然不是最優的。

RwLock<T> (Read-Write Lock) 正是為了解決這類“讀多寫少”的場景而設計的。它允許多個讀取者同時訪問共享數據，或者一個寫入者獨佔訪問共享數據。規則如下：

• 共享讀：可以有任意數量的讀取者同時持有讀鎖。
• 獨佔寫：當有寫入者持有寫鎖時，其他所有讀取者和寫入者都必須等待。
• 讀寫互斥：當有任何讀取者持有讀鎖時，寫入者必須等待；反之亦然。

RwLock 的核心特性：

• 提高讀併發：在讀取操作遠多於寫入操作時，RwLock 能顯著提高併發性能。
• 寫操作依然獨佔：保證了數據修改時的安全性。

Saga Reader 中的 RwLock 實戰

源碼：feed_api_rs/src/features/impl_default.rs

在 Saga Reader 的核心功能模塊 中，FeaturesAPIImpl 結構體持有一個 ApplicationContext，這個上下文中包含了用户配置 (UserConfig) 和應用配置 (AppConfig) 等共享狀態。這些配置信息會被多個 API 調用讀取，而修改配置的操作相對較少。

// ... existing code ...
use tokio::sync::RwLock; // 引入 Tokio 的異步 RwLock
// ... existing code ...

pub struct FeaturesAPIImpl {
    // ApplicationContext 被 Arc 和 RwLock 包裹，以便在異步任務間安全共享和併發訪問
    context: Arc<RwLock<ApplicationContext>>,
    scrap_provider: ScrapProviderEnums,
    article_recorder_service: ArticleRecorderService,
}

impl FeaturesAPIImpl {
    pub async fn new(ctx: ApplicationContext) -> anyhow::Result<Self> {
        // ... 初始化代碼 ...
        let context = Arc::new(RwLock::new(ctx)); // 創建 RwLock 實例
        // ...
        Ok(FeaturesAPIImpl {
            context,
            scrap_provider,
            article_recorder_service,
        })
    }

    // 示例：讀取配置 (讀操作)
    async fn update_feed_contents<R: Runtime>(
        &self,
        package_id: &str,
        feed_id: &str,
        app_handle: Option<AppHandle<R>>,
    ) -> anyhow::Result<()> {
        let user_config;
        let llm_section;
        {
            // 獲取讀鎖，允許多個任務同時讀取 context
            let context_guarded = self.context.read().await;
            user_config = context_guarded.user_config.clone();
            llm_section = context_guarded.app_config.llm.clone();
        } // 讀鎖在此處釋放
        // ... 後續邏輯使用 user_config 和 llm_section ...
        Ok(())
    }

    // 示例：修改用户配置 (寫操作)
    async fn add_feeds_package(&self, feeds_package: FeedsPackage) -> anyhow::Result<()> {
        // 獲取寫鎖，獨佔訪問 context
        let context_guarded = &mut self.context.write().await;
        let user_config = &mut context_guarded.user_config;
        if user_config.add_feeds_packages(feeds_package) {
            return self.sync_user_profile(user_config).await;
        }
        // ...
        Err(anyhow::Error::msg(
            "add_feeds_package failure, may be the feeds package already existed",
        ))
        // 寫鎖在此處釋放
    }
}

context: Arc<RwLock<ApplicationContext>> 使得 ApplicationContext 可以在多個異步的 API 請求處理任務之間安全地共享。當一個任務需要讀取配置，它會調用 self.context.read().await 來獲取一個讀鎖。多個任務可以同時持有讀鎖並訪問 ApplicationContext。當一個任務需要修改配置，它會調用 self.context.write().await 來獲取一個寫鎖。此時，其他任何嘗試獲取讀鎖或寫鎖的任務都會被阻塞，直到寫鎖被釋放。這種機制極大地提高了讀取密集型操作的併發性能，同時保證了寫操作的原子性和數據一致性。

關於 tauri::State 和 Arc：

我們經常看到 Tauri 命令的參數形如 state: State<'_, Arc<HybridRuntimeState>>。這裏的 Arc<HybridRuntimeState> 表明 HybridRuntimeState 是一個被多所有權共享的狀態對象。Tauri 的 State 管理器本身會確保以線程安全的方式將這個狀態注入到命令處理函數中。如果 HybridRuntimeState 內部的數據需要細粒度的併發控制，那麼它內部可能就會使用 Mutex 或 RwLock。例如，我們的 FeaturesAPIImpl 實例（它內部使用了 RwLock）就是通過 HybridRuntimeState 共享給各個 Tauri 命令的。

// ... existing code ...
// 在插件初始化時，創建 FeaturesAPIImpl 實例並放入 Arc 中
// 然後通過 app_handle.manage() 交給 Tauri 的狀態管理器
.setup(|app_handle, _plugin| {
    let features_api = tauri::async_runtime::block_on(async {
        let context_host = Startup::launch().await.unwrap();
        let context = context_host.copy_context();
        FeaturesAPIImpl::new(context).await.expect("tauri-plugin-feed-api setup the features instance failure")
    });

    app_handle.manage(Arc::new(HybridRuntimeState { features_api })); // features_api 內部有 RwLock
    Ok(())
})
// ... existing code ...

// ... existing code ...
// Tauri 命令通過 State 獲取共享的 HybridRuntimeState
#[tauri::command(rename_all = "snake_case")]
pub(crate) async fn get_feeds_packages(
    state: State<'_, Arc<HybridRuntimeState>>,
) -> Result<Vec<FeedsPackage>, ()> {
    // features_api 內部的 RwLock 會在這裏發揮作用
    let features_api = &state.features_api;
    Ok(features_api.get_feeds_packages().await)
}
// ... existing code ...

Mutex vs. RwLock：如何選擇？

選擇建議：

• 優先簡單：如果不確定，或者共享數據的訪問模式不清晰，可以從 Mutex 開始，因為它的語義更簡單，更不容易出錯。
• 分析瓶頸：如果性能分析表明某個 Mutex 成為了瓶頸，並且該場景符合“讀多寫少”的特點，那麼可以考慮替換為 RwLock。
• 警惕寫鎖飢餓：RwLock 的一個潛在問題是寫鎖飢餓。如果讀請求非常頻繁，寫操作可能長時間無法獲得鎖。一些 RwLock 的實現可能提供公平性策略來緩解這個問題，但仍需注意。
• 鎖的持有時間：無論使用 Mutex 還是 RwLock，都應儘可能縮短鎖的持有時間，以減少線程阻塞和提高併發度。將耗時操作移出臨界區（持有鎖的代碼段）。

總結與展望

Mutex 和 RwLock 是 Rust 併發編程中不可或缺的同步原語。它們以不同的策略平衡了數據安全和併發性能的需求。在 Saga Reader 項目中，我們根據具體的業務場景和數據訪問模式，恰當地選擇了 Mutex 來保證資源操作的串行化，以及 RwLock 來優化共享配置的併發讀取性能。

理解並熟練運用這些併發工具，是構建高效、健壯的 Rust 應用的基石。隨着項目的發展，我們也將持續關注併發性能，並在必要時對鎖的使用策略進行調優，以確保 Saga Reader 能夠為用户帶來流暢、穩定的閲讀體驗。

參與開源，一起構建高效閲讀器！

Saga Reader 是一個完全開源的跨平台項目，目前正在快速迭代中，急需以下方向的貢獻者：

• Rust 開發：優化併發邏輯、擴展本地大模型支持；
• 前端開發：基於 Svelte 優化用户交互；
• AI 算法：改進文本總結與伴讀功能的語義理解；

如何參與？

1. 🧑‍💻碼農🧑‍💻開源不易，各位好人路過請給個小星星💗Star💗。 → GitHub - Saga Reader
2. 加入 Issues 討論：提出功能建議或參與 Bug 修復；
3. 提交 PR：我們會提供詳細的開發文檔與技術支持！

福利：活躍貢獻者可獲得項目代碼署名！