Day 039 — MutexGuardを.awaitをまたいで持つと、なぜtokio::spawnがコンパイルできなくなるのか

📚 背景知識（読んでから問題へ）

Day 038ではtokio::spawnに渡すFutureが'static + Sendでなければならない、という制約を「借用が漏れ出す（'static違反）」の切り口から学びました。今日はもう一つの側面——Send違反——を扱います。実務のtokioコードで非常によく踏む地雷が、「std::sync::MutexGuardを.awaitをまたいで保持してしまう」バグです。

std::sync::Mutex<T>::lock()が返すMutexGuard<T>は、意図的にSendを実装していません（!Send——他スレッドへ移動できない設計です。これは「ロックを取得したスレッドとは別のスレッドからunlockされるとOS依存の未定義動作になりうる」というプラットフォームの制約を型で表現したものです）。

これは実行時のデータ競合ではなく、コンパイル時にRustが「実行時に起こりうる未定義動作」を型エラーとして先回りして止めてくれているという、Rustの所有権・借用システムの真骨頂とも言える挙動です。

📝 問題

以下は「アクセスカウンターをHashMapで管理し、複数のリクエストを並行処理する」ことを意図したコードですが、コンパイルが通りません。

📋 コピーuse std::collections::HashMap;
use std::sync::{Arc, Mutex};
use std::time::Duration;
use tokio::time::sleep;

async fn handle_request(counters: Arc<Mutex<HashMap<String, u32>>>, path: String) {
    let mut map = counters.lock().unwrap();
    let entry = map.entry(path.clone()).or_insert(0);
    *entry += 1;
    println!("[{path}] count = {entry}");

    // 外部APIへの問い合わせを模した非同期処理（ロックを持ったまま待ってしまっている）
    sleep(Duration::from_millis(50)).await;

    println!("[{path}] request handled");
}

#[tokio::main]
async fn main() {
    let counters: Arc<Mutex<HashMap<String, u32>>> = Arc::new(Mutex::new(HashMap::new()));

    let mut handles = Vec::new();
    for path in ["/users", "/orders", "/users"] {
        let counters = Arc::clone(&counters);
        handles.push(tokio::spawn(handle_request(counters, path.to_string())));
    }

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

要件1: このコードがtokio::spawnの箇所でなぜコンパイルエラーになるのか、原因をMutexGuardとSendトレイトの関係から説明してください。

要件2: std::sync::Mutexを使ったまま（tokio::sync::Mutexに変更せずに）コンパイルが通るように修正してください。ヒント: ロックを保持するスコープを.awaitより前で終わらせます。

要件3: 修正後のコードで、「ロックを保持している時間」と「.awaitで待っている時間」が完全に分離されていることを確認できるprintln!ログ、またはテストを追加してください。

🔍 ヒント（段階的開示）

📋 コピーasync fn handle_request(counters: Arc<Mutex<HashMap<String, u32>>>, path: String) {
    let count = {
        let mut map = counters.lock().unwrap();
        let entry = map.entry(path.clone()).or_insert(0);
        *entry += 1;
        *entry
        // ここでブロックが終わり、`map`(MutexGuard)がdropされる
    };
    println!("[{path}] count = {count}");

    sleep(Duration::from_millis(50)).await; // この時点でロックは一切保持していない

    println!("[{path}] request handled");
}

✅ 模範解答

📋 コピー// Cargo.toml に以下を追加して検証すること:
// [dependencies]
// tokio = { version = "1", features = ["full"] }

use std::collections::HashMap;
use std::sync::{Arc, Mutex};
use std::time::Duration;
use tokio::time::sleep;

/// 修正版: MutexGuardのスコープを`{ }`ブロックで明示的に区切り、
/// `.await`に到達する前にロックを解放してからawaitする。
/// これによりhandle_requestが返すFutureはロックを内部に保持し続けないため、
/// Sendトレイトを満たし、tokio::spawnに渡せるようになる。
async fn handle_request(counters: Arc<Mutex<HashMap<String, u32>>>, path: String) {
    // --- ロックを保持する区間はこのブロック内だけに限定する ---
    let count = {
        let mut map = counters.lock().unwrap();
        let entry = map.entry(path.clone()).or_insert(0);
        *entry += 1;
        *entry
        // ブロック終端で`map`(MutexGuard)がdropされ、ロックが解放される
    };
    println!("[{path}] count = {count} (lock released here)");

    // --- ここに到達した時点でロックは一切保持していない ---
    sleep(Duration::from_millis(50)).await;

    println!("[{path}] request handled");
}

#[tokio::main]
async fn main() {
    let counters: Arc<Mutex<HashMap<String, u32>>> = Arc::new(Mutex::new(HashMap::new()));

    let mut handles = Vec::new();
    for path in ["/users", "/orders", "/users"] {
        let counters = Arc::clone(&counters);
        handles.push(tokio::spawn(handle_request(counters, path.to_string())));
    }

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

    let final_map = counters.lock().unwrap();
    println!("最終カウント: {final_map:?}");
    assert_eq!(final_map.get("/users"), Some(&2));
    assert_eq!(final_map.get("/orders"), Some(&1));
}

#[cfg(test)]
mod tests {
    use super::*;

    /// ロックを保持している時間と.awaitで待っている時間が
    /// 分離されていることを確認するテスト。
    /// もしロックをまたいで.awaitしていたら、このテスト自体が
    /// (Sendでないため)コンパイルの時点で失敗するはずである。
    #[tokio::test]
    async fn lock_is_released_before_await() {
        let counters: Arc<Mutex<HashMap<String, u32>>> = Arc::new(Mutex::new(HashMap::new()));

        // 3つのタスクを並行spawnできること自体が、
        // handle_requestの返すFutureがSendであることの証明になる。
        let mut handles = Vec::new();
        for path in ["/a", "/b", "/a"] {
            let counters = Arc::clone(&counters);
            handles.push(tokio::spawn(handle_request(counters, path.to_string())));
        }
        for handle in handles {
            handle.await.unwrap();
        }

        let map = counters.lock().unwrap();
        assert_eq!(map.get("/a"), Some(&2));
        assert_eq!(map.get("/b"), Some(&1));
    }
}

🪜 Step-by-Step 解説

💡 設計思想・なぜこう書くのか

このバグが型エラーとして現れること自体が、Rustの所有権システムの価値を最も分かりやすく示す例の一つです。もしこれがC++やJavaであれば、「マルチスレッドランタイムがロックを取得したのとは別のスレッドでロックを解放しようとする」というバグは、プラットフォームによっては動くこともあれば、実行時にクラッシュしたり、稀にしか再現しないデータ競合になったりする——つまり「本番環境の特定条件でしか踏まないバグ」になりがちです。

🛑 コンパイルエラーが出た場合

問題のコード（修正前）をtokio::spawnに渡すと、次のようなエラーが出ます（tokioのバージョンにより文言は多少異なります）。

🌐 他言語との比較

GoやJavaでも「ロックを持ったまま長時間待つな」という同種のベストプラクティスは存在しますが、それを守るかどうかは開発者の規律に委ねられています。RustはMutexGuardに!Sendという型レベルの制約を持たせることで、tokioのマルチスレッドランタイムという特定の文脈においては、このベストプラクティス違反をコンパイラが強制的に握りつぶすという一歩踏み込んだ設計を取っています。

🏆 実務での使いどころ

• Webサーバーの共有状態管理: リクエストカウンター・キャッシュ・コネクションプールの空き状況などをArc<Mutex<T>>で管理する際、DBやHTTPクライアントへの.awaitをロックの外に追い出す設計は、tokioを使う実務コードで最も頻繁に登場するリファクタリングパターンの一つ
• tokio::sync::Mutexとの使い分けの判断材料: 「ロックを持ったまま非同期I/Oを待つ必要が構造上どうしてもある」場合はtokio::sync::Mutex（非同期対応・.awaitをまたげる）に切り替える選択肢もあるが、それは「ロック保持時間を延ばす」ことと同義であり、まずは今回のようにロック保持区間を縮めてstd::sync::Mutexのまま解決できないかを先に検討するのが定石
• コードレビューの着眼点: PRレビューでasync fn内に.lock()と.awaitが両方登場していたら、両者の間に他の.awaitが挟まっていないか（＝ロックを保持したままの.awaitが発生していないか）を機械的にチェックする習慣が、実務での事故防止に直結する

⚠️ よくある誤解・ミス

🚀 次のステップ

• 発展: 今回のhandle_requestを、tokio::sync::Mutex版でも実装し、std::sync::Mutex版と比べて「ロックを解放するタイミング」がどう変わるかをログで比較してみましょう
• 次回予告: async trait（async-trait / RPITIT） — トレイトに非同期メソッドを持たせる設計と、async-traitクレートとRPITIT（Return Position Impl Trait In Trait）の使い分けに進みます

🎯 自己評価

自分の回答

気づき・メモ