Day 047 — Boxのヒープ確保コストは推測ではなく実測する。enum静的ディスパッチ vs async-trait動的ディスパッチ

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

Day 046では「なぜネイティブのasync fn in traitだけではトレイトオブジェクトが作れないのか」を確認し、async-traitクレートがPin<Box<dyn Future<...> + Send>>への変換を肩代わりしてくれることを学びました。今日はその「肩代わり」に実際どれだけのコストが乗っているのかを、言葉ではなく実測で確認します。

Rustには「複数の実装を1箇所で切り替える」ための道具が実はもう1つあります。enumによる静的な多態性です。

📋 コピーenum AnyNotifier {
    Email(EmailNotifier),
    Slack(SlackNotifier),
}

このenumに対してmatchで分岐すれば、EmailNotifierかSlackNotifierかによって呼び出す処理を変えられます。これはdyn Notifierによるトレイトオブジェクトと似た「実行時に決まる複数実装の切り替え」を実現しますが、決定的に違う点があります。具体型の集合がコンパイル時に閉じている（AnyNotifierは未来永劫この2種類しか持てない）ことと引き換えに、matchの各腕は単相化された具体的な関数呼び出しになり、Box<dyn Future>によるヒープ確保が一切不要になる、という点です。

つまり実務での選択はこうなります。

• 実装の集合が閉じている（プラグインを外部クレートが追加することはない、種類は自分たちで把握しきれる）→ enum + ネイティブasync fn in traitで静的ディスパッチ
• 実装の集合が開いている（外部クレートやランタイム設定で実装が増減しうる）→ async-trait + dyn Traitで動的ディスパッチ

📝 問題

Day 046のNotifier（メール・Slack通知）を題材に、以下を実装してください。

1. ネイティブasync fn in trait版（async-traitマクロなし）でtrait Notifierを定義し、EmailNotifier・SlackNotifierに実装する
2. ジェネリクス経由で呼び出すasync fn dispatch_one<N: Notifier>(notifier: &N, message: &str) -> Result<(), String>を実装する
3. EmailNotifierとSlackNotifierを1つのVecにまとめて扱うため、enumによる静的ディスパッチAnyNotifier（Email/Slackのバリアントを持つ）を定義し、send_alertメソッドをmatchで実装する
4. 比較対象として、Day 046と同じasync-trait版（DynNotifierという名前にして区別する）も同じファイルに実装する
5. Systemアロケータをラップして確保回数をカウントするCountingAllocator（GlobalAllocトレイト実装）を作り、#[global_allocator]に設定する
6. main関数で、以下を計測して標準出力に表示する
   • カウンタをリセットしたあと、AnyNotifierのVecに対して1,000回×2件のメッセージ送信ループを回し、確保回数を記録する
   • カウンタを再度リセットしたあと、Vec<Box<dyn DynNotifier>>に対して同じ1,000回×2件のループを回し、確保回数を記録する
   • 2つの確保回数を出力し、差を確認する
7. 以下をテストで検証してください
   • dispatch_oneがEmailNotifierに対して正しく成功/失敗を返すこと
   • AnyNotifier::Email・AnyNotifier::Slackそれぞれが正しく成功/失敗を返すこと
8. 確認課題: ネイティブ版のNotifierでVec<Box<dyn Notifier>>を作ろうとするとどうなるか。実際にコンパイルしてエラーメッセージを確認し、Day 046で見たエラーと同じかどうかコメントで残してください

🔍 ヒント（段階的開示）

📋 コピーuse std::alloc::{GlobalAlloc, Layout, System};
use std::sync::atomic::{AtomicUsize, Ordering};

struct CountingAllocator;
static ALLOC_COUNT: AtomicUsize = AtomicUsize::new(0);

unsafe impl GlobalAlloc for CountingAllocator {
    unsafe fn alloc(&self, layout: Layout) -> *mut u8 {
        ALLOC_COUNT.fetch_add(1, Ordering::Relaxed);
        System.alloc(layout)
    }
    unsafe fn dealloc(&self, ptr: *mut u8, layout: Layout) {
        System.dealloc(ptr, layout)
    }
}

#[global_allocator]
static ALLOCATOR: CountingAllocator = CountingAllocator;

fn reset_alloc_count() -> usize {
    ALLOC_COUNT.swap(0, Ordering::Relaxed)
}

// AnyNotifier / DynNotifier 側は、Vecを先に作ってから
// reset_alloc_count() → ループ → reset_alloc_count() で
// 「ループ内で起きた確保だけ」を切り出す

✅ 模範解答

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

use async_trait::async_trait;
use std::alloc::{GlobalAlloc, Layout, System};
use std::sync::atomic::{AtomicUsize, Ordering};

// ============================================================
// 計測用: ヒープ確保回数をカウントするグローバルアロケータ
// ============================================================

struct CountingAllocator;

static ALLOC_COUNT: AtomicUsize = AtomicUsize::new(0);

unsafe impl GlobalAlloc for CountingAllocator {
    unsafe fn alloc(&self, layout: Layout) -> *mut u8 {
        ALLOC_COUNT.fetch_add(1, Ordering::Relaxed);
        System.alloc(layout)
    }
    unsafe fn dealloc(&self, ptr: *mut u8, layout: Layout) {
        System.dealloc(ptr, layout)
    }
}

#[global_allocator]
static ALLOCATOR: CountingAllocator = CountingAllocator;

/// 現在の確保回数を取得し、同時に0にリセットする。
/// 「計測したい区間の直前」に必ず呼ぶことで、それ以前の
/// 初期化コストを計測結果から除外する。
fn reset_alloc_count() -> usize {
    ALLOC_COUNT.swap(0, Ordering::Relaxed)
}

// ============================================================
// ① ネイティブ async fn in trait（静的ディスパッチ）
// ============================================================

trait Notifier {
    async fn send_alert(&self, message: &str) -> Result<(), String>;
}

struct EmailNotifier {
    address: String,
}

impl Notifier for EmailNotifier {
    async fn send_alert(&self, message: &str) -> Result<(), String> {
        if message.is_empty() {
            return Err(format!("email to {} rejected: empty message", self.address));
        }
        Ok(())
    }
}

struct SlackNotifier {
    channel: String,
}

impl Notifier for SlackNotifier {
    async fn send_alert(&self, message: &str) -> Result<(), String> {
        if message.len() > 200 {
            return Err(format!("slack #{}: message too long ({} chars)", self.channel, message.len()));
        }
        Ok(())
    }
}

/// ジェネリクス経由の静的ディスパッチ。呼び出し箇所ごとに
/// 具体型`N`が確定しているため、コンパイラは`EmailNotifier`用・
/// `SlackNotifier`用それぞれの専用コードを単相化で生成する。
/// `Notifier::send_alert`の戻り値である匿名の`impl Future`は、
/// スタック上に置ける具体的なサイズを持つ型として扱われる。
async fn dispatch_one(notifier: &N, message: &str) -> Result<(), String> {
    notifier.send_alert(message).await
}

/// 実装の集合が「EmailNotifierとSlackNotifierの2つだけ」と
/// コンパイル時に分かっている場合、トレイトオブジェクトの
/// 代わりにenumで「静的な多態性」を実現できる。matchの各腕は
/// 単相化された具体的な呼び出しであり、Boxは
/// 一切登場しない。
enum AnyNotifier {
    Email(EmailNotifier),
    Slack(SlackNotifier),
}

impl AnyNotifier {
    async fn send_alert(&self, message: &str) -> Result<(), String> {
        match self {
            AnyNotifier::Email(n) => n.send_alert(message).await,
            AnyNotifier::Slack(n) => n.send_alert(message).await,
        }
    }
}

// ============================================================
// ② async-trait（動的ディスパッチ、Day 046の再掲）
// ============================================================

#[async_trait]
trait DynNotifier: Send + Sync {
    async fn send_alert(&self, message: &str) -> Result<(), String>;
}

struct DynEmailNotifier {
    address: String,
}

#[async_trait]
impl DynNotifier for DynEmailNotifier {
    async fn send_alert(&self, message: &str) -> Result<(), String> {
        if message.is_empty() {
            return Err(format!("email to {} rejected: empty message", self.address));
        }
        Ok(())
    }
}

struct DynSlackNotifier {
    channel: String,
}

#[async_trait]
impl DynNotifier for DynSlackNotifier {
    async fn send_alert(&self, message: &str) -> Result<(), String> {
        if message.len() > 200 {
            return Err(format!("slack #{}: message too long ({} chars)", self.channel, message.len()));
        }
        Ok(())
    }
}

const ITERATIONS: usize = 1_000;

#[tokio::main]
async fn main() {
    // ---- 静的ディスパッチ（enum + ネイティブ async fn）の計測 ----
    let notifiers = vec![
        AnyNotifier::Email(EmailNotifier { address: "ops@example.com".to_string() }),
        AnyNotifier::Slack(SlackNotifier { channel: "incidents".to_string() }),
    ];

    reset_alloc_count(); // Vec構築コストは計測対象から除外する
    for _ in 0..ITERATIONS {
        for n in ¬ifiers {
            let _ = n.send_alert("disk usage exceeded 90%").await;
        }
    }
    let static_allocs = reset_alloc_count();

    // ---- 動的ディスパッチ（async-trait）の計測 ----
    let dyn_notifiers: Vec> = vec![
        Box::new(DynEmailNotifier { address: "ops@example.com".to_string() }),
        Box::new(DynSlackNotifier { channel: "incidents".to_string() }),
    ];

    reset_alloc_count();
    for _ in 0..ITERATIONS {
        for n in &dyn_notifiers {
            let _ = n.send_alert("disk usage exceeded 90%").await;
        }
    }
    let dyn_allocs = reset_alloc_count();

    println!(
        "static dispatch (enum + native async fn): {static_allocs:>5} allocations  ({ITERATIONS} iterations x 2 notifiers)"
    );
    println!(
        "dynamic dispatch (async-trait):           {dyn_allocs:>5} allocations  ({ITERATIONS} iterations x 2 notifiers)"
    );

    // dispatch_one の動作確認（ジェネリクス経由の呼び出し例）
    let email = EmailNotifier { address: "solo@example.com".to_string() };
    let result = dispatch_one(&email, "hello").await;
    println!("dispatch_one result: {result:?}");
}

// --- 確認課題の結果 ---
//
// ネイティブ版のtrait Notifierのまま
// `let v: Vec> = vec![...];` を書こうとすると:
//
//   error[E0038]: the trait `Notifier` cannot be made into an object
//    --> src/main.rs:NN:35
//     |
//   NN |     let v: Vec> = vec![
//      |                    ^^^^^^^^^^^^ `Notifier` cannot be made into an object
//     |
//     = note: because this trait contains one or more async functions
//     = help: consider using the `async_trait` crate:
//             https://crates.io/crates/async-trait
//
// Day 046で見たエラーと本質的に同じ（E0038、
// 「async fnを含むトレイトはobject-safeではない」）。
// async-trait版のDynNotifierを別名で定義しているかどうかは
// 無関係で、「素のasync fn in trait」自体がdyn非互換という
// 制約はどの型にも一律に適用される、という点を再確認できる。

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

    #[tokio::test]
    async fn dispatch_one_generic_reports_success_and_failure() {
        let email = EmailNotifier { address: "a@b.com".to_string() };

        let ok = dispatch_one(&email, "hello").await;
        assert!(ok.is_ok());

        let err = dispatch_one(&email, "").await;
        assert!(err.is_err());
    }

    #[tokio::test]
    async fn any_notifier_email_variant_dispatches_correctly() {
        let email = AnyNotifier::Email(EmailNotifier { address: "a@b.com".to_string() });

        assert!(email.send_alert("hi").await.is_ok());
        assert!(email.send_alert("").await.is_err());
    }

    #[tokio::test]
    async fn any_notifier_slack_variant_dispatches_correctly() {
        let slack = AnyNotifier::Slack(SlackNotifier { channel: "x".to_string() });

        assert!(slack.send_alert("hi").await.is_ok());
        let too_long = "x".repeat(201);
        assert!(slack.send_alert(&too_long).await.is_err());
    }
}

🪜 Step-by-Step 解説

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

Rustが「トレイトオブジェクト」と「enumによる静的多態性」という2つの異なる多態性の仕組みを両方提供しているのは偶然ではありません。オブジェクト指向言語の多くは「多態性 = 動的ディスパッチ」を暗黙の前提としますが、Rustは「拡張性が必要な開いた集合」と「集合が閉じていて全部把握できる」を意識的に区別させる設計を取っています。閉じた集合に対してわざわざ動的ディスパッチとヒープ確保のコストを払う理由はなく、enumで表現すればmatchの網羅性チェックという追加の安全性まで手に入ります。「多態性が欲しい」という要求を鵜呑みにせず、「その多態性は本当に実行時まで種類が分からない、閉じていない集合なのか」を問い直すことが、Rustらしい設計判断の第一歩です。

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

Notifier（ネイティブ版）のままでVec<Box<dyn Notifier>>を作ろうとすると、Day 046と同じE0038が出ます。

📋 コピー// アンチパターン: ネイティブ async fn in trait を dyn 化しようとする
trait Notifier {
    async fn send_alert(&self, message: &str) -> Result<(), String>;
}

let v: Vec> = vec![
    Box::new(EmailNotifier { address: "x".to_string() }),
];

🌐 他言語との比較

RustのenumはJavaのsealed interfaceが持つ「網羅性チェック」という利点と、C言語のunionに近い「スタック上に収まる値型」という性質を両立しています。「実装の集合を閉じたい」という設計意図がある場合、Rustではそれをenumとして型システムに直接刻み込める点が、動的型のUnionしか持たないTypeScriptや、保証のないGoの型スイッチとの大きな違いです。

🏆 実務での使いどころ

• 決済プロバイダの切り替え: 自社が対応する決済手段が「クレジットカード・銀行振込・電子マネー」の3種類と決まっている（新しい決済手段の追加は仕様変更を伴う大きなイベント）場合、enumディスパッチで実装すると、新プロバイダ追加時にmatchの網羅性チェックが「対応漏れの処理箇所」をコンパイルエラーで教えてくれる
• プラグインシステム: サードパーティが実装を追加できる、または設定ファイルで実行時に有効/無効を切り替える必要がある場合は、開いた集合なのでdyn Trait（async-trait）が適している
• 高頻度なホットパス: ゲームサーバーのフレーム処理、ネットワークプロキシのパケット処理など、1秒間に数万回呼ばれるような処理では、Boxによるヒープ確保の積み重ねが無視できないレイテンシになりうるため、可能な限りenumディスパッチ（または単純なジェネリクス）に倒す
• 段階的な移行: 最初は種類が少なく閉じていた実装が、将来的にプラグイン化されそうな兆しがあるなら、早い段階で「今は閉じているが、開く可能性がある」ことをチームで共有し、enumからdyn Traitへの移行コストを見積もっておく

⚠️ よくある誤解・ミス

🚀 次のステップ

• 発展: CountingAllocatorにサイズ別の合計バイト数（AtomicUsizeをもう1つ増やし、layout.size()を加算）も記録し、「確保回数は同じでもサイズが違う」ケース（大きなStringをエラーメッセージに使う場合など）で挙動がどう変わるか確認する
• 次回予告: unsafe Rustの基礎（生ポインタ操作） — 5つのunsafe操作と、コンパイラが保証してくれなくなる境界線がどこかを学ぶ

🎯 自己評価

自分の回答

気づき・メモ