Ownership in Rust: Speichersicherheit ohne GC

1. Überblick

Ownership ist der Kernmechanismus, der Rust ermöglicht, Speichersicherheit ohne Garbage Collector (GC) wie in Java oder Go und ohne manuelles malloc/free wie in C zu gewährleisten. Dieser Artikel erklärt die drei Ownership-Regeln, das Borrowing-Konzept, Lifetimes und häufige Compile-Zeit-Fehler. Nach dem Lesen werden Sie verstehen, warum Rust beim Compilieren “pingelig” ist, aber dafür ist es frei von Dangling Pointers, Double-Free-Fehlern und Data Races zur Laufzeit.

2. Das Problem: Speicherverwaltung ohne GC

Sprachen wie Java nutzen Garbage Collection, um Speicher freizugeben — bequem, aber mit CPU-Overhead und unvorhersehbaren Pausen. C/C++ geben dir volle Kontrolle, aber führen leicht zu Double-Free-, Use-After-Free- und Memory-Leak-Fehlern. Rust wählt einen dritten Weg: Der Compiler verfolgt, wer die “Eigentümer” bestimmter Daten sind, und gibt Speicher automatisch frei, wenn der Eigentümer den Gültigkeitsbereich verlässt. Kein Runtime-Overhead, kein GC-Thread nötig.

fn main() {
    let s = String::from("Non La Dev");
    println!("{s}");
} // s verlässt hier den Scope, Rust ruft automatisch drop(s) auf und gibt den Heap-Speicher frei

String::from allociert Speicher auf dem Heap. Wenn die Variable s den Gültigkeitsbereich (}) verlässt, erzeugt Rust automatisch einen drop-Aufruf — ähnlich wie finally { free(s) }, aber vom Compiler erzeugt, ohne dass du es selbst schreiben musst.

3. Die drei Ownership-Regeln

Rust hat genau drei Regeln — wenn du diese auswendig lernst, verstehst du 80% des Mechanismus:

1. Jeder Wert in Rust hat eine Variable, die als Eigentümer (Owner) bezeichnet wird.
2. Es gibt nur einen Eigentümer zur gleichen Zeit.
3. Wenn der Eigentümer den Gültigkeitsbereich verlässt, wird der Wert gelöscht (dropped).

3.1. Move-Semantik

fn main() {
    let s1 = String::from("hello");
    let s2 = s1; // Eigenschaft "move" von s1 zu s2

    println!("{s2}");
    // println!("{s1}"); // Fehler compile-Zeit: s1 wurde verschoben
}

Anders als Java (wo das Zuweisen einer Variablen nur die Referenz kopiert und beide auf dasselbe Objekt zeigen), sieht Rust let s2 = s1 als Übertragung der Eigentümerschaft an. Nach dieser Zeile ist s1 nicht mehr gültig. Wenn du die letzte Zeile freigibst, erhältst du einen Fehler:

error[E0382]: borrow of moved value: `s1`
  --> src/main.rs:5:20
   |
2  |     let s1 = String::from("hello");
   |         -- move occurs because `s1` has type `String`
3  |     let s2 = s1;
   |              -- value moved here
4  |
5  |     println!("{s1}");
   |                ^^^^ value borrowed here after move

Dies verhindert grundlegend den Fehler Double-Free: Wenn sowohl s1 als auch s2 denselben Heap-Zeiger halten würden, würde Rust versuchen, beide zweimal freizugeben — was zu Abstürzen führt. Der Compiler blockiert dies bereits zur Compile-Zeit.

3.2. Clone, wenn du beide behalten möchtest

Wenn du wirklich zwei unabhängige Kopien brauchst, rufe .clone() explizit auf:

fn main() {
    let s1 = String::from("hello");
    let s2 = s1.clone(); // Deep Copy des Heap-Speicherbereichs

    println!("{s1} - {s2}"); // beide sind gültig
}

.clone() allociert einen neuen Heap-Bereich und kopiert den Inhalt dorthin. Die Runtime-Kosten sind offensichtlich, und Rust zwingt dich, dies explizit aufzurufen, damit niemand versehentlich eine riesige Datenstruktur kopiert, ohne es zu bemerken — im Gegensatz zu vielen Sprachen, die stillschweigend kopieren.

3.3. Copy-Trait für einfache Datentypen

fn main() {
    let x = 5;
    let y = x; // kopieren, nicht verschieben

    println!("x = {x}, y = {y}"); // beide funktionieren noch
}

Primitive Typen wie i32, bool, char und Tuples mit nur solchen Typen implementieren das Copy-Trait. Da sie eine feste Größe haben und vollständig auf dem Stack liegen, ist das Kopieren billiger als ein Move, daher kopiert Rust dies automatisch, anstatt die ursprüngliche Variable ungültig zu machen.

Hinweis: Ein Typ kann nicht sowohl Copy als auch Drop implementieren. Wenn ein Typ Ressourcen hat, die freigegeben werden müssen (Heap, Datei-Handle…), darf es Copy nicht implementieren.

4. Ownership beim Übergeben an Funktionen

Das Übergeben einer Variablen an eine Funktion folgt derselben Move-Semantik wie das Zuweisen:

fn print_order(order: String) {
    println!("Order: {order}");
} // order wird hier gelöscht, nicht beim Aufrufer

fn main() {
    let order = String::from("ORDER-001");
    print_order(order);
    // println!("{order}"); // Fehler: order wurde in die Funktion verschoben
}

Beim Aufruf von print_order(order) wird die Eigentümerschaft von order an den Parameter der Funktion übertragen. Wenn die Funktion endet, wird der Wert innerhalb der Funktion gelöscht — main hat kein Recht mehr, order zu verwenden. Deshalb ist Borrowing (nächster Abschnitt) fast immer notwendig, wenn du Daten nur “ausleihen” möchtest, ohne die Eigentümerschaft zu übertragen.

5. Borrowing: Ausleihen ohne Eigentümerschaft zu übertragen

5.1. Unveränderliche Referenz (&T)

fn print_order(order: &String) {
    println!("Order: {order}");
}

fn main() {
    let order = String::from("ORDER-001");
    print_order(&order); // ausleihen, nicht verschieben
    println!("Noch verwendbar: {order}");
}

Das &-Zeichen erzeugt eine Referenz — es leiht Daten aus, ohne die Eigentümerschaft zu übernehmen. Die Funktion print_order liest nur, besitzt order aber nicht. Nachdem die Funktion endet, hat main immer noch volle Kontrolle über die ursprüngliche Variable.

5.2. Veränderbare Referenz (&mut T)

fn add_discount(total: &mut f64) {
    *total -= 10.0;
}

fn main() {
    let mut total = 100.0;
    add_discount(&mut total);
    println!("Total: {total}"); // Total: 90
}

&mut erlaubt das Ausleihen zum Ändern. Um es aufzurufen, muss die ursprüngliche Variable mit mut deklariert sein. Das *-Zeichen wird verwendet, um die Referenz zu dereferenzieren und einen neuen Wert in den Speicher zu schreiben, auf den die Referenz zeigt.

5.3. Borrowing-Regeln

Rust setzt zur Compile-Zeit zwei Ausleihregeln durch, gemeinsam bekannt als Borrow Checker:

• Zu einem Zeitpunkt kann es entweder eine veränderbare Referenz oder mehrere unveränderbare Referenzen geben — nicht beides zusammen.
• Eine Referenz darf nie länger leben als die ursprüngliche Daten (verhindert Dangling References).

fn main() {
    let mut total = 100.0;

    let r1 = &total;
    let r2 = &total; // OK: mehrere unveränderbare Referenzen gleichzeitig
    println!("{r1} {r2}");

    let r3 = &mut total; // Fehler, wenn r1, r2 danach noch verwendet werden
    println!("{r3}");
}

Wenn r1 und r2 nach der ersten println! nicht mehr verwendet werden, erlaubt der Compiler (dank Non-Lexical Lifetimes) r3, darunter veränderbar auszuleihen. Aber wenn du versuchst, r1 nach dem Erscheinen von r3 zu verwenden, erhältst du:

error[E0502]: cannot borrow `total` as mutable because it is also borrowed as immutable

Diese Regel beseitigt Data Races zur Compile-Zeit: Es kann nicht gleichzeitig jemanden lesen und jemand anderen schreiben auf derselben Speicherstelle.

6. Lifetime: Sicherstellen, dass Referenzen nicht ins “Nichts” zeigen

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

fn main() {
    let order1 = String::from("ORDER-001");
    let order2 = String::from("ORDER-002-LONG");

    let result = longest(order1.as_str(), order2.as_str());
    println!("Das längere: {result}");
}

Die Notation 'a ist eine Lifetime-Annotation und sagt dem Compiler: “Die zurückgegebene Referenz lebt nicht länger als sowohl x als auch y”. Rust kann die Beziehung zwischen mehreren Referenzen in diesem Fall nicht selbst erraten, daher musst du dies explizit deklarieren. Meistens leitet Rust Lifetimes selbst ab (Lifetime Elision), daher schreibst du 'a selten manuell — nur wenn eine Funktion mehrere Referenzen akzeptiert und eine zurückgibt.

error[E0106]: missing lifetime specifier
 --> src/main.rs:1:33
  |
1 | fn longest(x: &str, y: &str) -> &str {
   |                                 ^ expected named lifetime parameter

Ohne 'a beschwert sich der Compiler, weil er nicht weiß, ob die zurückgegebene Referenz zu x oder y gehört.

7. Wenn mehrere Eigentümer nötig sind: Rc und RefCell

Single-Owner-Ownership ist manchmal zu streng, beispielsweise beim Aufbau von Baumstrukturen oder Graphen, wo mehrere Knoten auf denselben Wert verweisen möchten.

<!-- Keine zusätzliche Abhängigkeit erforderlich, Rc/RefCell befinden sich in std -->

use std::cell::RefCell;
use std::rc::Rc;

struct Customer {
    name: String,
    balance: RefCell<f64>,
}

fn main() {
    let customer = Rc::new(Customer {
        name: String::from("Nón Lá"),
        balance: RefCell::new(0.0),
    });

    let c1 = Rc::clone(&customer);
    let c2 = Rc::clone(&customer);

    *c1.balance.borrow_mut() += 50.0;
    *c2.balance.borrow_mut() += 30.0;

    println!("{} balance = {}", customer.name, customer.balance.borrow());
    println!("Anzahl der Referenzen: {}", Rc::strong_count(&customer));
}

Rc<T> (Reference Counted) erlaubt mehreren Eigentümern, auf unveränderbare Daten zu zeigen, zählt Referenzen zur Laufzeit und löscht automatisch bei Null. RefCell<T> erlaubt veränderliches Borgen zur Laufzeit anstatt zur Compile-Zeit (Interior Mutability) — als Ausgleich wird dein Programm panic, wenn du die Borrowing-Regeln verletzt (z.B. zweimal borrow_mut() gleichzeitig), anstatt einen Compile-Fehler zu zeigen.

Nón Lá balance = 80
Anzahl der Referenzen: 3

Hinweis: Rc/RefCell sind nur für Single-Threaded-Code. Für Multi-Thread-Datenfreigabe verwende Arc (Atomic Reference Count) mit Mutex oder RwLock. Verwende nicht wahllos Rc<RefCell<T>> — es nimmt dir den großen Vorteil weg, dass Rust Fehler zur Compile-Zeit auffängt, was Rusts Stärke ist.

8. Tests schreiben, um Ownership-Verhalten zu überprüfen

#[derive(Clone)]
struct Order {
    id: String,
    amount: f64,
}

fn apply_discount(order: &mut Order, percent: f64) {
    order.amount -= order.amount * percent / 100.0;
}

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

    #[test]
    fn should_keep_original_order_untouched_when_cloned() {
        let original = Order { id: "ORD-1".into(), amount: 100.0 };
        let mut copy = original.clone();

        apply_discount(&mut copy, 10.0);

        assert_eq!(original.amount, 100.0); // Original wird nicht verändert
        assert_eq!(copy.amount, 90.0);
    }

    #[test]
    fn should_mutate_through_mutable_borrow() {
        let mut order = Order { id: "ORD-2".into(), amount: 200.0 };
        apply_discount(&mut order, 25.0);

        assert_eq!(order.amount, 150.0);
    }
}

Führe cargo test aus, Ergebnis:

running 2 tests
test tests::should_keep_original_order_untouched_when_cloned ... ok
test tests::should_mutate_through_mutable_borrow ... ok

test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured

Der erste Test beweist, dass .clone() eine unabhängige Kopie erzeugt — Änderungen an copy beeinflussen original nicht. Der zweite Test bestätigt, dass &mut tatsächlich die ursprünglichen Daten durch die Referenz ändert.

9. Häufige Fehler

• Use after move: Du versuchst, eine Variable nach einem Move an anderer Stelle (Funktion, neue Variable, Struktur) zu verwenden. Behebe dies mit .clone(), wenn du zwei Kopien brauchst, oder wechsle zu Referenzen (&T).
• Cannot borrow as mutable more than once: Du hältst einen &mut, aber erstellst dann ein weiteres & oder &mut gleichzeitig. Verkürze den Gültigkeitsbereich der alten Referenz (mit Block {} oder lasse sie früher enden) um das zu beheben.
• Dangling reference: Du gibst eine Referenz zurück, die auf eine lokale Variable zeigt, die gelöscht wird, wenn die Funktion endet. Rust blockiert dies vollständig zur Compile-Zeit — du wirst Fehler wie missing lifetime specifier oder borrowed value does not live long enough sehen.
• Missbrauch von .clone() zur Umgehung des Borrow Checkers: Syntaktisch gültig, aber unnötig ineffizient. Sieh jeden .clone()-Aufruf als Frage: “Brauche ich wirklich eine unabhängige Kopie, oder weiche ich nur Ownership-Verständnis aus?”

10. Wann ist striktes Ownership übertrieben?

Wenn du schnelle Scripts, Prototypen oder kleine Datenmengen ohne strenge Anforderungen an Sicherheit und Leistung schreibst, könnte der Aufwand, den Borrow Checker zu verstehen und einzuhalten, nicht wert sein — Sprachen wie Python oder Go bieten schnellere Entwicklungsgeschwindigkeit. Ownership glänzt dort, wo Systeme hohe Leistung und strikte Speichersicherheit erfordern: Betriebssysteme, Embedded-Systeme, Spiele-Engines oder Backend-Services mit niedrigen Latenzen, die GC-Pausen nicht tolerieren.

11. Fazit

Ownership ist das Fundament, das Rust ermöglicht, einen scheinbaren Widerspruch zu lösen: Speichersicherheit wie bei GC-Sprachen, aber Leistung wie C/C++. Die drei Regeln (Owner-Move-Drop), der Borrowing-Mechanismus mit der “ein-veränderbar-oder-mehrere-unveränderbar”-Regel und Lifetime-Annotationen arbeiten zusammen, sodass der Compiler Memory-Unsafety bereits zur Compile-Zeit auffängt, anstatt es bei Laufzeit crashen zu lassen. Am Anfang kann der Borrow Checker frustrierend sein, aber sobald du dich daran gewöhnt hast, schreibst du Code mit weniger Bugs als in anderen Sprachen — ohne dass eine Runtime-Instanz dich überwachen muss.