Rust Lifetimes verstehen: Annotationen, Elision und Interview-Fragen 2026

Rust Lifetimes sind der Mechanismus, mit dem der Compiler die Gültigkeit von Referenzen nachverfolgt. Im Gegensatz zu Sprachen mit Garbage Collection, bei denen die Speicherverwaltung zur Laufzeit erfolgt, validiert der Borrow Checker von Rust die Gültigkeit von Referenzen zur Kompilierzeit und eliminiert damit ganze Kategorien von Speicherfehlern, bevor der Code überhaupt ausgeführt wird.

Was Lifetimes tatsächlich im Speicher darstellen

Lifetimes beschreiben nicht, wie lange Werte existieren. Sie beschreiben, wie lange Referenzen auf Werte gültig bleiben. Jede Referenz in Rust hat einen Lifetime, auch wenn Annotationen weggelassen werden.

Betrachten wir diese Funktion, die der Compiler ablehnt:

fn create_dangling() -> &String {
    let s = String::from("hello");
    &s  // ERROR: `s` is dropped at end of function
}

Der String s lebt nur innerhalb des Funktions-Scopes. Eine Referenz darauf zurückzugeben würde einen Dangling Pointer erzeugen, da der Speicher des Strings freigegeben wird, wenn die Funktion zurückkehrt. Der Borrow Checker erkennt dies zur Kompilierzeit.

Die Lösung erfordert entweder die Rückgabe eines owned Values oder die Sicherstellung, dass die referenzierten Daten den Funktionsaufruf überleben:

// Option 1: Return owned value
fn create_owned() -> String {
    String::from("hello")
}

// Option 2: Reference data that outlives the function
fn first_word(s: &str) -> &str {
    s.split_whitespace().next().unwrap_or("")
}

In first_word borgt der zurückgegebene &str vom Input s, sodass er gültig bleibt, solange s existiert. Der Aufrufer kontrolliert den Lifetime des Inputs.

Syntax und Semantik von Lifetime-Annotationen

Explizite Lifetime-Annotationen verwenden die Syntax 'a, 'b und so weiter. Diese sind keine Anweisungen an den Compiler, wie lange Referenzen leben sollen. Sie beschreiben Beziehungen zwischen den Lifetimes mehrerer Referenzen.

Die Rust Reference definiert Lifetime-Annotationen als generische Parameter, die einschränken, wie lange Referenzen relativ zueinander gültig sein müssen.

// Both inputs and output share the same lifetime 'a
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");
    let result;
    {
        let string2 = String::from("short");
        result = longest(&string1, &string2);
        println!("Longest: {}", result);  // Valid: both strings alive
    }
    // println!("{}", result);  // ERROR: string2 dropped
}

Die Annotation 'a teilt dem Compiler mit: Die zurückgegebene Referenz wird für die Schnittmenge der Lifetimes von x und y gültig sein. Da string2 einen kürzeren Lifetime hat, kann result nicht verwendet werden, nachdem string2 gelöscht wurde.

Mehrere unterschiedliche Lifetimes drücken komplexere Beziehungen aus:

// Output tied only to first parameter's lifetime
fn first_only<'a, 'b>(x: &'a str, _y: &'b str) -> &'a str {
    x
}

fn main() {
    let owned = String::from("owned");
    let result;
    {
        let temporary = String::from("temporary");
        result = first_only(&owned, &temporary);
    }
    // result still valid: only depends on owned
    println!("{}", result);
}

Lifetime-Elision-Regeln in Rust 2024

Der Compiler wendet drei Elision-Regeln an, um Lifetimes zu inferieren, wenn Annotationen weggelassen werden. Diese Regeln, dokumentiert im Rustonomicon, reduzieren Boilerplate ohne die Sicherheit zu beeinträchtigen.

Diese Regeln decken die meisten gängigen Muster ab:

// Rule 1: Each input gets own lifetime
fn takes_two(x: &str, y: &str) {}
// Compiler reads: fn takes_two<'a, 'b>(x: &'a str, y: &'b str) {}

// Rule 2: Single input lifetime propagates to output  
fn first_char(s: &str) -> &str {
    &s[0..1]
}
// Compiler reads: fn first_char<'a>(s: &'a str) -> &'a str

// Rule 3: &self lifetime propagates to output
impl Parser {
    fn peek(&self) -> &Token {
        &self.tokens[self.position]
    }
    // Compiler reads: fn peek<'a>(&'a self) -> &'a Token
}

Wenn Elision fehlschlägt, verlangt der Compiler explizite Annotationen. Dies geschieht am häufigsten bei Funktionen, die Referenzen zurückgeben, die von mehreren Inputs abgeleitet sind:

// ERROR: Can't determine output lifetime
fn ambiguous(x: &str, y: &str) -> &str {
    if x.len() > y.len() { x } else { y }
}

// FIX: Explicit annotation resolves ambiguity
fn unambiguous<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() { x } else { y }
}

Struct-Lifetimes und die Outlives-Beziehung

Structs, die Referenzen enthalten, erfordern Lifetime-Annotationen, um auszudrücken, dass geborgte Daten länger leben müssen als das Struct:

struct Excerpt<'a> {
    text: &'a str,
}

impl<'a> Excerpt<'a> {
    // new borrows from input, so Excerpt can't outlive the source
    fn new(source: &'a str, start: usize, end: usize) -> Self {
        Excerpt { text: &source[start..end] }
    }
    
    // level() returns owned data, no lifetime in signature
    fn level(&self) -> u32 {
        self.text.len() as u32 / 10
    }
}

fn main() {
    let novel = String::from("Call me Ishmael. Some years ago...");
    let excerpt = Excerpt::new(&novel, 0, 16);
    println!("Excerpt: {}", excerpt.text);
}  // novel dropped, but excerpt already out of scope

Das 'a in Excerpt<'a> bindet die Gültigkeit des Structs an den Lifetime des geborgten text. Der Versuch, ein Excerpt zu verwenden, nachdem sein Quell-String gelöscht wurde, löst einen Kompilierfehler aus.

Für Structs mit mehreren Referenzen kann jede unterschiedliche Lifetimes haben:

struct Comparison<'a, 'b> {
    baseline: &'a str,
    candidate: &'b str,
}

impl<'a, 'b> Comparison<'a, 'b> {
    fn new(baseline: &'a str, candidate: &'b str) -> Self {
        Comparison { baseline, candidate }
    }
    
    fn baseline_only(&self) -> &'a str {
        self.baseline
    }
}

Der 'static Lifetime und wann man ihn verwendet

Der 'static Lifetime zeigt an, dass Daten für die gesamte Programmausführung leben. String-Literale haben diesen Lifetime, weil sie in die Binary eingebettet sind:

let s: &'static str = "I live forever";

// Constants are implicitly 'static
const CONFIG_VERSION: &str = "2.0.0";

// Thread-safe globals require 'static
static COUNTER: AtomicU64 = AtomicU64::new(0);

Ein häufiges Muster beinhaltet T: 'static Bounds, was Entwickler oft verwirrt. Dieser Bound bedeutet, dass T keine nicht-statischen Referenzen enthält, nicht dass T eine Referenz sein muss:

use std::thread;

fn spawn_task<T: Send + 'static>(data: T) {
    thread::spawn(move || {
        // data moved into thread, must live independently
        println!("Processing in thread");
    });
}

fn main() {
    let owned = String::from("owned data");
    spawn_task(owned);  // OK: String is 'static (owns its data)
    
    let reference = "borrowed";
    // spawn_task(reference);  // OK: &'static str
}

Der Thread könnte länger leben als die aufrufende Funktion, daher dürfen Daten, die in Threads verschoben werden, keine Referenzen auf Stack-lokale Variablen enthalten.

Häufige Lifetime-Fehler und ihre Lösungen

Mehrere Muster bringen Entwickler regelmäßig ins Stolpern. Das Verständnis dieser beschleunigt das Debugging.

Rückgabe von Referenzen auf lokale Variablen:

fn bad_split(text: &str, delimiter: char) -> (&str, &str) {
    let parts: Vec<&str> = text.split(delimiter).collect();
    (parts[0], parts[1])  // OK: parts[i] borrow from text, not from Vec
}

fn truly_bad() -> &str {
    let local = String::from("local");
    &local  // ERROR: local dropped at end of function
}

Speichern von Referenzen in Structs mit nicht übereinstimmenden Lifetimes:

struct Cache {
    data: String,
    // view: &str,  // ERROR: needs lifetime parameter
}

// Self-referential structs require unsafe or crates like ouroboros
struct CacheWithView<'a> {
    data: String,
    view: Option<&'a str>,  // Can't point to self.data safely
}

Selbstreferenzierende Structs, bei denen ein Feld auf ein anderes Feld verweist, erfordern entweder Pin mit unsicherem Code oder Crates wie ouroboros. Das Modul Rust Smart Pointers behandelt diese fortgeschrittenen Muster.

Lifetime-Bounds bei Trait-Implementierungen:

trait Processor {
    fn process<'a>(&self, input: &'a str) -> &'a str;
}

struct Prefixer {
    prefix: String,
}

impl Processor for Prefixer {
    // Can't return &format!(...) - would be temporary
    fn process<'a>(&self, input: &'a str) -> &'a str {
        input  // Must return input or part of it
    }
}

Higher-Ranked Trait Bounds (HRTBs) für generische Lifetimes

Higher-Ranked Trait Bounds verwenden die for<'a> Syntax, um auszudrücken, dass ein Typ ein Trait für jeden Lifetime erfüllen muss, nicht nur für einen bestimmten:

use std::fmt::Debug;

// F must be callable with any lifetime 'a
fn apply_to_refs<F>(f: F)
where
    F: for<'a> Fn(&'a str) -> &'a str,
{
    let owned = String::from("test");
    let result = f(&owned);
    println!("{}", result);
}

fn identity(s: &str) -> &str { s }

fn main() {
    apply_to_refs(identity);
}

HRTBs erscheinen häufig in APIs, die Closures akzeptieren, und im Rust async/await Ökosystem, wo Futures mit Referenzen unterschiedlicher Lifetimes arbeiten müssen.

Interview-Fragen zu Rust Lifetimes

Technische Interviews prüfen das Verständnis von Lifetimes auf mehreren Ebenen. Diese Fragen erscheinen regelmäßig bei Rust-Positionen.

Frage: Warum kompiliert dieser Code nicht?

fn get_str() -> &str {
    "hello"
}

Antwort: Der Rückgabetyp benötigt eine explizite Lifetime-Annotation. Obwohl das String-Literal einen 'static Lifetime hat, drückt die Funktionssignatur dies nicht aus. Die Lösung: fn get_str() -> &'static str.

Frage: Erkläre, warum dies kompiliert und ob es sicher ist:

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

Antwort: Dies kompiliert, weil der Output-Lifetime nur an x gebunden ist. Der _y Parameter kann jeden Lifetime haben, da der Rückgabewert nicht von ihm abhängt. Dies ist sicher: Die Gültigkeit der zurückgegebenen Referenz hängt ausschließlich vom Lifetime von x ab.

Frage: Was passiert, wenn man versucht, eine Referenz neben owned Daten zu speichern?

struct Config<'a> {
    name: String,
    description: &'a str,
}

Antwort: Dieses Muster ist gültig, schränkt aber ein, wie Config verwendet werden kann. Das Struct kann nicht länger leben als das, worauf description verweist. Für owned Daten, die auf sich selbst verweisen müssen, sollte man erwägen, String für beide Felder zu verwenden, oder Techniken, die in Rust Ownership und Borrowing behandelt werden.

Frage: Wie interagieren Lifetimes mit Trait Objects?

trait Formatter {
    fn format(&self, input: &str) -> String;
}

fn get_formatter<'a>() -> Box<dyn Formatter + 'a> {
    // ...
}

Antwort: Trait Objects haben standardmäßig einen impliziten 'static Lifetime-Bound. Das Schreiben von Box<dyn Formatter + 'a> erlaubt explizit, dass das Trait Object Referenzen mit Lifetime 'a enthält. Ohne den expliziten Bound entspricht Box<dyn Formatter> Box<dyn Formatter + 'static>.

Lifetime-Varianz: Kovarianz und Kontravarianz

Varianz bestimmt, wie Lifetimes zusammenhängen, wenn Typen verschachtelt sind. Rust-Referenzen folgen diesen Regeln:

• &'a T ist kovariant in 'a: Ein längerer Lifetime kann einen kürzeren ersetzen
• &'a mut T ist invariant in T: Der Typ muss exakt übereinstimmen
• fn(&'a T) ist kontravariant in 'a: Ein kürzerer Lifetime kann einen längeren ersetzen

fn covariant_example() {
    let s: &'static str = "static";
    let r: &str = s;  // OK: 'static lives longer than any 'a
}

fn invariant_example() {
    let mut vec: Vec<&'static str> = vec!["a"];
    // let s = String::from("local");
    // vec.push(&s);  // ERROR: &s is not &'static str
}

Das Verständnis von Varianz ist wichtig beim Design von generischen APIs, die Referenzen akzeptieren oder zurückgeben. Der Artikel Rust Traits und Generics behandelt fortgeschrittene generische Muster.

Lifetime-Annotationen in der Praxis: Wichtige Erkenntnisse

• Lifetimes beschreiben die Gültigkeit von Referenzen, nicht die Existenz von Werten. Der Borrow Checker verwendet sie, um Dangling Pointer zur Kompilierzeit zu verhindern.
• Elision-Regeln behandeln die meisten Fälle automatisch. Explizite Annotationen werden notwendig, wenn Referenzen zurückgegeben werden, die von mehreren Inputs abgeleitet sind.
• Struct-Lifetimes drücken die Outlives-Beziehung aus: Jedes Struct, das Referenzen enthält, muss durch die Lifetimes dieser Referenzen parametrisiert sein.
• Der 'static Bound auf Generics bedeutet "enthält keine nicht-statischen Referenzen", nicht "muss eine Referenz sein".
• Selbstreferenzierende Structs erfordern spezielle Behandlung durch Pin, unsicheren Code oder Hilfs-Crates.
• Interview-Fragen konzentrieren sich darauf zu verstehen, warum Code nicht kompiliert und wie Lifetime-Annotationen die Gültigkeitsgarantien ändern.