Antwort.

Vorgeschichte der Frage

In C/C++ und anderen niedrigstufigen Sprachen muss der Entwickler die Datenplatzierung im Speicher ausdrücklich verwalten: im Stack (automatische Variablen) oder im Heap (Zuweisung über malloc/new). In diesen Sprachen treten häufig Fehler wie Speicherlecks, doppelte Freigabe oder die Verwendung von nicht initialisiertem oder bereits freigegebenem Speicher auf. Rust übernimmt die Aufgabe, den Speicher streng durch ein Besitzsystem zu kontrollieren, ohne einen Garbage Collector.

Problem

Die automatische Speicherverwaltung über den Stack ist bequem, aber in der Größe (Stacktiefe) begrenzt. Die Zuweisung im Heap erfordert eine ausdrückliche Verwaltung der Ressourcen, was gefährlich ist: man kann vergessen, den Speicher freizugeben oder die Lebensräume von Zeigern zu verletzen. Ein Garbage Collector ist nicht immer eine Lösung (Ressourcenkosten, unvorhersehbare Pausen). Fehler bei der Speicherverwaltung führen zu Abstürzen und Sicherheitsanfälligkeiten.

Lösung

In Rust unterscheiden sich Stack und Heap durch automatische Verwaltung: Alle Werte werden standardmäßig auf dem Stack abgelegt, während für dynamisch dimensionierte oder langlebige Objekte der Heap über intelligente Zeiger (z. B. Box<T>, Vec<T>) verwendet wird. Das Besitz- und Ausleihsystem gewährleistet, dass Ressourcen nach Übertragung des Besitzes oder nach Beendigung des Lebensraums automatisch freigegeben werden. All dies gewährleistet Sicherheit zur Kompilierungszeit und vermeidet überflüssige Pausen durch einen Garbage Collector.

Beispielcode:

fn main() {
    let a = 42;                         // Stack-Zuweisung
    let b = Box::new(42);               // Heap-Zuweisung
    let mut v = Vec::new();
    v.push(1); v.push(2);               // Array-Daten im Heap
}

Wesentliche Merkmale:

Standardmäßig werden einfache Typen (Copy) im Stack abgelegt.
Dynamische Sammlungen und Box<T> verwenden den Heap, werden jedoch durch RAII freigegeben.
Aller Speicher wird garantiert ohne manuelles Eingreifen oder GC freigegeben.

Trickfragen.

Kann man Speicher auf dem Stack manuell freigeben (drop)?

Nein. Die Freigabe von stack-allocierten Variablen erfolgt automatisch beim Verlassen des Geltungsbereichs; das manuelle Durchführen von drop ist nutzlos und sogar unzulässig für Stack-Zeiger.

Führt das Verschieben (move) zu einer Übertragung in den Heap?

Nein. Das Verschieben einer Variablen zwischen Besitzern bedeutet nicht notwendigerweise, dass sie in den Heap verschoben wird; nur der Besitz ändert sich.

Garantiert die Verwendung von Box<T>, dass T immer im Heap ist?

Ja, Box<T> weist T tatsächlich im Heap zu, jedoch wird das Besitz- und Lebensraumverständnis weiterhin streng kontrolliert.

Typische Fehler und Antipatterns

Verwirrung über die Lebensräume von Referenzen, Versuche, eine Referenz auf ein lokales Stack-Objekt aus einer Funktion zurückzugeben.
Verwendung des Heaps für kleine Objekte ohne Notwendigkeit (malloc-Overhead).
Missachtung des Besitzes und der Move-Semantik für Sammlungen und Box<T>.

Praxisbeispiel

Negativer Fall

Im Projekt werden globale Vektoren (Vec<T>) mit einer manuellen Bereinigung über mem::forget oder drop verwendet, wobei manchmal hängende Zeiger auf freigegebenen Speicher zurückbleiben.

Vorteile:

Viel Flexibilität und manuelle Ressourcenverwaltung.

Nachteile:

Hohes Risiko von Fehlern und Lecks, verminderte Sicherheit.

Positiver Fall

Objekte werden ausdrücklich über Box platziert, die Datenübertragung erfolgt nach dem Besitzprinzip, für Sammlungen werden intelligente Zeiger verwendet und es werden keine Referenzen auf Stack-Variablen zurückgegeben.