Speicher und Garbage Collector in Rust: Wie eine Sprache ohne GC Ressourcen verwaltet

Warum Rust keinen Garbage Collector benötigt, aber dennoch sicher ist?

Wenn Entwickler, die an Python, Java oder C# gewöhnt sind, zum ersten Mal von Rust hören, erschreckt sie oft das Fehlen eines gewohnten Garbage Collectors (GC). „Wie soll das gehen? – denken sie. – Ohne GC kehren wir zurück in die Ära der manuellen Speicherverwaltung, mit Speicherlecks und Segmentation Faults?“

Spoiler: Nein, das tun wir nicht. Rust bietet einen dritten Weg – das Ownership-System, das Speichersicherheit bereits zur Kompilierzeit garantiert. Keine Laufzeit, kein GC, keine hängenden Zeiger. Nur klare Regeln und ein Compiler, der verhindert, dass Sie sich ins Knie schießen.

In diesem Artikel werden wir untersuchen, wie der Speicher in Rust funktioniert, was RAII, Ownership, Borrowing und Lebensdauer sind und warum all dies Rust zu einer der zuverlässigsten Sprachen für die Systemprogrammierung macht.

Wie ist der Speicher in Rust aufgebaut: Stack und Heap

Wie in jeder Low-Level-Sprache wird der Speicher in Rust in zwei Hauptbereiche unterteilt:

\n
• Stack – schneller, in der Größe begrenzter Speicher, der nach dem LIFO-Prinzip funktioniert. Hier werden lokale Variablen, Funktionsargumente und Rücksprungadressen gespeichert.
\n
• Heap – langsamerer, aber flexiblerer Speicher, der für Daten verwendet wird, deren Größe zum Zeitpunkt der Kompilierung unbekannt ist (z. B. String, Vec, Box).
\n

In C++ entscheiden Sie selbst, wann Sie den Heap allozieren und freigeben (über new/delete). In Java oder Python erledigt dies der Garbage Collector für Sie, indem er das Programm regelmäßig anhält. Rust hingegen verwendet ein Ownership-System, das den Speicher automatisch freigibt, sobald eine Variable den Gültigkeitsbereich verlässt.

Beispiel: Basis-Speicherallokation

fn main() {\n    let s = String::from("Hallo, Welt!"); // Speicherallokation auf dem Heap\n    println!("{}", s);\n} // hier verlässt s den Gültigkeitsbereich, der Speicher wird freigegeben

Beachten Sie: kein free() oder delete. Am Ende des Blocks fügt der Compiler implizit einen Aufruf des Destruktors ein – drop(). Dies wird als RAII (Resource Acquisition Is Initialization) bezeichnet – die Ressource wird bei der Initialisierung erfasst und bei der Zerstörung des Objekts freigegeben.

Ownership: Die Hauptregel von Rust

Das Ownership-System in Rust basiert auf drei einfachen Regeln:

\n
1. Jeder Wert in Rust hat genau einen Besitzer (Owner).
\n
2. Wenn der Besitzer den Gültigkeitsbereich verlässt, wird der Wert gelöscht.
\n
3. Der Besitzer kann übertragen (Move) oder vorübergehend ausgeliehen (Borrow) werden.
\n

Klingt langweilig? Sehen wir uns an, wie das in der Praxis funktioniert.

Move

fn main() {\n    let s1 = String::from("hello");\n    let s2 = s1; // s1 wird nach s2 verschoben\n    // println!("{}", s1); // Fehler! s1 besitzt die Daten nicht mehr\n    println!("{}", s2); // OK\n}

In C++ würde eine solche Zuweisung zu zwei Zeigern auf denselben Speicher führen – und zu einer doppelten Freigabe. In Rust verbietet der Compiler einfach die Verwendung von s1 nach dem Verschieben. Keine Speicherlecks, keine doppelten Löschungen.

Copy

Einfache Typen wie ganze Zahlen, boolesche Werte und Zeichen implementieren das Copy-Trait. Bei ihnen erzeugt die Zuweisung eine vollständige Kopie:

fn main() {\n    let x = 42;\n    let y = x;\n    println!("x = {}, y = {}", x, y); // Beide sind verfügbar!\n}

Warum das? Weil i32 auf dem Stack gespeichert wird und das Kopieren lediglich das Kopieren einiger Bytes bedeutet. Günstig und sicher.

Borrowing und Referenzen

Was tun, wenn Sie vorübergehend Zugriff auf Daten gewähren möchten, ohne das Ownership zu übertragen? Verwenden Sie Referenzen. Rust erlaubt es, einen Wert per Referenz auszuleihen.

fn main() {\n    let s = String::from(