Antwort.

Historie der Frage:

In Rust wurde das Management von Ressourcen ohne Garbage Collector dank strenger Eigentums- und Lebenszyklusregeln von Objekten möglich. Zur Automatisierung der Freigabe von Ressourcen (z. B. Dateideskriptoren, Sockets, Speicher von externen Bibliotheken) wurde von Anfang an das Trait Drop eingeführt. Dies ist der Hauptweg zur "Reaktion" auf das Ende der Lebensdauer eines Objekts, der Anwendung findet zur Finalisierung und Rückgabe von Ressourcen an das Betriebssystem oder zur Freigabe von Speicher.

Problem:

Gewöhnliche Rust-Typen reinigen automatisch ihre eigenen Ressourcen, aber wenn eine Struktur eine Ressource speichert, die manuell freigegeben werden muss (z. B. eine geöffnete Datei oder ein unsicherer Zeiger), kann das Versäumnis oder Vergessen des Entwicklers zu Leaks oder Race Conditions führen. Wenn Drop falsch implementiert wird (z. B. die Möglichkeit einer doppelten Speicherfreigabe nicht berücksichtigt wird), kann dies zu Laufzeitfehlern führen.

Lösung:

Das Trait Drop erlaubt es, eine spezielle Methode drop(&mut self) zu definieren, die automatisch beim Zerstören eines Wertes aufgerufen wird. Es ist geeignet, Ressourcen genau dann freizugeben, wenn ein Objekt den Sichtbarkeitsbereich verlässt. Es ist wichtig, daran zu denken, dass Ressourcen (z. B. Dateien schließen) nur hier freigegeben werden sollten.

Beispielcode:

struct RawFile {
    handle: *mut libc::FILE,
}

impl Drop for RawFile {
    fn drop(&mut self) {
        if !self.handle.is_null() {
            unsafe {
                libc::fclose(self.handle);
            }
        }
    }
}

Wichtige Merkmale:

Die Methode drop wird nicht explizit aufgerufen — nur vom Compiler.
Drop wird nur für Strukturen implementiert, die eine nicht-Rust-Ressource besitzen.
Drop wird standardmäßig nicht bei einem Leak durch mem::forget oder panic! (außerhalb von unwinding) aufgerufen.

Trickfragen.

Kann man drop für ein Objekt explizit aufrufen, um die Ressource vorzeitig freizugeben?

Nein, die direkte Aufrufung der Methode drop (&obj.drop()) ist verboten — nur durch die Funktion std::mem::drop(obj), die das Eigentum an dem Objekt übernimmt und drop automatisch aufruft. Der direkte Aufruf von drop() wird nicht kompiliert.

Beispielcode:

fn main() {
    let f = File::open("foo.txt").unwrap();
    // drop(&mut f); // Kompilierungsfehler!
    std::mem::drop(f); // Richtig: Datei schließen
}

Was passiert, wenn eine Struktur mit Drop unter memcpy oder move fällt? Wird der Destruktor nicht zweimal aufgerufen?

Nein, der Destruktor wird immer genau einmal während des gesamten Lebenszyklus eines Objekts aufgerufen, und der Compiler überwacht dies. Aber wenn man unsichere Kopien von "rohen" Bytes einer Struktur macht oder mem::forget verwendet, wird drop möglicherweise überhaupt nicht aufgerufen — daher die Gefahr.

Kann man Drop und Copy gleichzeitig für denselben Typ implementieren?

Nein, der Compiler verbietet diese Kombination: Ein Typ, der Drop implementiert, kann nicht Copy sein, um einen einmaligen Aufruf des Destruktors zu garantieren und doppelte Freigaben der Ressource auszuschließen.

Typische Fehler und Anti-Patterns

Direktaufruf der drop-Methode (nicht erlaubt)
Nicht freigegebene Ressource oder nicht geschlossene Datei aufgrund des Vergessens von Drop
Nutzung nach Freigabe (use after free) durch unsicheren Pointer
Implementierung von Drop gleichzeitig mit Copy (Kompilierungsfehler)
Komplexe Eigentumsketten, bei denen die Reihenfolge von drop kritisch ist

Lebensbeispiel

Negativer Fall

Ein Programmierer hat eine einfache Hülle zur Arbeit mit einer geöffneten Datei geschrieben, aber vergessen, Drop zu implementieren und den Deskriptor beim Löschen des Objekts zu schließen.

Vorteile:

Kein überflüssiger Code, Struktur ist einfach zu verstehen

Nachteile:

Nach dem Verlassen der Datei aus dem Sichtbarkeitsbereich bleibt der Deskriptor offen
Es kann zu einer Erschöpfung der Deskriptoren und zum Ausfall des Betriebssystems kommen

Positiver Fall

Ein Entwickler hat Drop für die Hülle des Dateideskriptors implementiert und schließt die Datei explizit in drop. Nun wird die Ressource garantiert freigegeben, wenn irgendeine Variable dieser Struktur die Funktion oder den Panic verlässt.