Zenn
🧬

Rustのライフタイム徹底解説：メモリ管理を理解する

2025/03/05に公開
Rust
Web
プログラミング
backend
tech

表紙

ライフタイムとは

ライフタイムの定義

Rust において、すべての参照（リファレンス）にはライフタイムが存在します。つまり、その参照が指している値がメモリ上に存在する期間（または、参照がコード内で有効な行数）を指します。ライフタイムは、参照がそのライフタイム全体にわたって有効であることを保証するために使用されます。これは、参照の安全性を確保するために不可欠です。

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

上記のコードでは、関数 longest は 2 つの入力引数を持っており、それぞれ文字列スライスの参照です。また、返り値も文字列スライスの参照となっています。Rust はメモリ安全性を重視する言語であるため、参照の有効性を保証するためにライフタイムの概念が導入されました。ライフタイムを使用することで、参照が有効かどうかをコンパイル時に検証できます。

この関数の返り値のライフタイムをどのように決定するのでしょうか？Rust にはライフタイム推論機能があり、関数の引数や返り値のライフタイムを自動的に推測することができます。ただし、Rust はすべてのケースでライフタイムを推測できるわけではありません。Rust が自動推論できるのは 3 つの特定のケースのみであり、上記のコードはそのいずれにも該当しません。そのため、この関数では明示的にライフタイムを指定する必要があります。ライフタイムを指定しなければ、Rust の借用チェッカーは返り値のライフタイムを特定できず、参照の有効性を検証できなくなります。

上記のコードのように、返り値が引数のいずれかに由来する場合、その返り値のライフタイムは、少なくとも関数の実行中は有効である必要があります。しかし、引数が 2 つあるため、それぞれ異なるライフタイムを持つ可能性があります。その場合、どちらのライフタイムに合わせればよいのでしょうか？この問題は、返り値のライフタイムを引数のうち最も短いライフタイムと一致させることで解決できます。つまり、返り値のライフタイムは 2 つの引数のライフタイムの交差部分（共通する最短の期間）になります。このルールを適用することで、Rust の借用チェッカーが参照の有効性を確認できるようになります。

ライフタイムとメモリ管理

Rust はライフタイムを使用してメモリを管理します。変数がスコープを抜けると、その変数が占有していたメモリは解放されます。しかし、解放されたメモリを指す参照が残っている場合、その参照は「ダングリングポインタ」（無効な参照）になり、これを使用するとコンパイルエラーになります。

fn main() {
    let r;

    {
        let x = 5;
        r = &x;
    }

    println!("r: {}", r);
}

上記のコードでは、変数 x はスコープを抜けるとメモリが解放されます。しかし、変数 r は x への参照を保持したままです。このような状態では、r は解放済みのメモリを指してしまい、ダングリングポインタとなります。Rust のコンパイラはこのような状況を検出し、エラーを出力します。

なぜライフタイムが必要なのか

ダングリングポインタを防ぎ、メモリ安全性を確保

前述のように、Rust はライフタイムを使用してダングリングポインタを防ぎます。コンパイラはすべての参照のライフタイムをチェックし、それらが有効な範囲内で使用されるように保証します。

fn main() {
    let string1 = String::from("abcd");
    let string2 = "xyz";

    let result = longest(string1.as_str(), string2);
    println!("The longest string is {}", result);
}

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

上記のコードでは、関数 longest は文字列スライスの参照を返します。コンパイラはこの返り値のライフタイムが適切かどうかをチェックし、もしダングリングポインタが発生する可能性がある場合はエラーを出します。

次に、ライフタイムがメモリ安全性をどのように確保するかを示す簡単な例を見てみましょう：

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

fn main() {
    let string1 = String::from("long string is long");
    let result;
    {
        let string2 = String::from("xyz");
        result = longest(string1.as_str(), string2.as_str());
    }
    println!("The longest string is {}", result);
}

このコードでは、longest 関数は 2 つの文字列スライスを引数に取り、ライフタイムパラメータ 'a を使って、それらのライフタイムを明示的に関連付けています。

main 関数内で string1 と string2 の 2 つの文字列を作成し、それらのスライスを longest に渡しています。しかし、string2 はスコープを抜けるとメモリが解放されます。そのため、result に string2 への参照が格納されてしまうと、result はダングリングポインタになり、Rust のコンパイラはエラーを出します。これにより、メモリ安全性が確保されます。

ライフタイムの文法

ライフタイムの明示的な指定

関数の定義において、ライフタイムパラメータを山括弧 (<>) で指定できます。ライフタイムパラメータの名前は、アポストロフィ (') で始める必要があります。例えば 'a という名前を使うことが一般的です。

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

このコードでは、longest 関数の引数 x と y の両方にライフタイム 'a が付いています。また、返り値にも 'a が指定されており、これは「返り値のライフタイムは x と y のライフタイムと同じである」という意味になります。

ライフタイム省略規則

多くの場合、Rust のコンパイラはライフタイムを自動推論できます。この場合、明示的なライフタイム指定を省略できます。

fn longest(x: &str, y: &str) -> &str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

このコードでは、コンパイラは longest の引数と返り値のライフタイムを推測できないため、エラーを出します。なぜなら、longest の返り値が x から来るのか、y から来るのかが実行時まで決定できず、どのライフタイムを採用すべきか分からないからです。

そのため、以下のようにライフタイムを明示的に指定する必要があります。

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

Rust では、ライフタイム省略規則（Lifetime Elision Rules）に基づき、特定のケースではライフタイムを自動的に推論できます。以下の 3 つの規則があります。

  1. 各参照引数は独自のライフタイムを持つ

    • 例えば、関数 fn foo(x: &i32) は、内部的に fn foo<'a>(x: &'a i32) と解釈されます。

  2. 関数に 1 つの参照引数しかない場合、それはすべての返り値に適用される

    • 例えば、fn foo<'a>(x: &'a i32) -> &i32 は、内部的に fn foo<'a>(x: &'a i32) -> &'a i32 と解釈されます。

  3. 複数の参照引数があり、そのうちの 1 つが &self または &mut self である場合、それがすべての返り値に適用される

    • 例えば、fn foo(&self, x: &i32) -> &i32 は、fn foo<'a, 'b>(&'a self, x: &'b i32) -> &'a i32 と解釈されます。

このように、Rust コンパイラはライフタイムを自動推論できますが、複雑なケースでは明示的な指定が必要になることがあります。

ライフタイムの使用場面

関数の引数と返り値

関数の引数や返り値に参照を含む場合、ライフタイムを指定することで参照の有効性を保証できます。

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

このコードでは、関数 longest の 2 つの引数 x と y はそれぞれ 'a というライフタイムを持ち、返り値も同じ 'a というライフタイムを持ちます。これは、「返り値のライフタイムは x と y のライフタイムの範囲内で有効であること」を示します。

構造体におけるライフタイム

構造体内で参照を持つ場合、その参照の有効性を保証するためにライフタイムを指定する必要があります。

struct ImportantExcerpt<'a> {
    part: &'a str,
}

fn main() {
    let novel = String::from("Call me Ishmael. Some years ago...");
    let first_sentence = novel.split('.').next().expect("Could not find a '.'");
    let i = ImportantExcerpt { part: first_sentence };
}

このコードでは、ImportantExcerpt 構造体は文字列スライスの参照を持っています。そのため、ライフタイムパラメータ 'a を指定することで、その参照がスコープの外で無効にならないようにしています。

つまり、ImportantExcerpt のライフタイムは part が有効な間のみ存在できることを Rust コンパイラに保証させています。これにより、無効な参照を防ぐことができます。

ライフタイムの高度な使い方

ライフタイムのサブタイピングとポリモーフィズム

Rust ではライフタイムのサブタイピング（継承関係）やポリモーフィズムをサポートしています。ライフタイムのサブタイピングとは、あるライフタイムが別のライフタイムを包含できることを意味します。

fn longest<'a>(x: &'a str, y: &str) -> &'a str {
    x
}

このコードでは、longest 関数の x はライフタイム 'a を持っていますが、y はライフタイムを持っていません。これは、y のライフタイムが x に影響しないことを意味します。つまり、y は任意のライフタイムを持つことができ、関数の返り値には影響しません。

'static ライフタイム

Rust には特別なライフタイム 'static があり、これは「プログラムの実行全体にわたって有効な参照」を意味します。

let s: &'static str = "I have a static lifetime.";

このコードでは、s は 'static ライフタイムを持つ文字列スライスです。"I have a static lifetime." はプログラムの実行中ずっとメモリに保持されるため、その参照は 'static となります。

ライフタイムと借用チェッカー

借用チェッカーの役割

Rust のコンパイラには「借用チェッカー（borrow checker）」と呼ばれる仕組みがあり、コード内のすべての参照が適切なルールに従っているかを検証します。不適切な借用が発生すると、コンパイルエラーになります。

fn main() {
    let mut s = String::from("hello");

    let r1 = &s;
    let r2 = &s;
    let r3 = &mut s;

    println!("{}, {}, and {}", r1, r2, r3);
}

このコードでは、s に対して同時に不変参照 (r1, r2) と可変参照 (r3) を作成しようとしています。Rust の借用ルールに違反しているため、コンパイルエラーになります。

借用チェッカーは、ライフタイムのチェックだけでなく、可変性のルールも考慮します。同じスコープ内で 複数の不変参照 を持つことは許可されていますが、可変参照があるときに不変参照を作成することはできません。これにより、データ競合を防ぎます。

ライフタイムの制約

Rust のライフタイムシステムはメモリの安全性を保証する強力な機能ですが、一方で以下のような制約もあります。

  • ライフタイムを明示的に記述する必要がある
    自動推論ができない場合、開発者が明示的にライフタイムを指定する必要があります。これはコードの可読性を下げる可能性があります。

  • ライフタイムの推論が難しい場合がある
    ライフタイムが複雑に絡み合う場合、Rust のコンパイラは適切なライフタイムを推測できず、エラーを出すことがあります。この場合、開発者は設計を見直し、よりシンプルな構造にする必要があります。

私たちはLeapcell、Rustプロジェクトのホスティングの最適解です。

Leapcell

Leapcellは、Webホスティング、非同期タスク、Redis向けの次世代サーバーレスプラットフォームです：

複数言語サポート

  • Node.js、Python、Go、Rustで開発できます。

無制限のプロジェクトデプロイ

  • 使用量に応じて料金を支払い、リクエストがなければ料金は発生しません。

比類のないコスト効率

  • 使用量に応じた支払い、アイドル時間は課金されません。
  • 例: $25で6.94Mリクエスト、平均応答時間60ms。

洗練された開発者体験

  • 直感的なUIで簡単に設定できます。
  • 完全自動化されたCI/CDパイプラインとGitOps統合。
  • 実行可能なインサイトのためのリアルタイムのメトリクスとログ。

簡単なスケーラビリティと高パフォーマンス

  • 高い同時実行性を容易に処理するためのオートスケーリング。
  • ゼロ運用オーバーヘッド — 構築に集中できます。

ドキュメントで詳細を確認！

Try Leapcell

Xでフォローする：@LeapcellHQ

ブログでこの記事を読む

Discussion