Antwort.

Geschichte der Frage:

Ein Goroutine-Leck ist eine Situation, in der eine Goroutine weiterhin im Speicher existiert und "hängt", obwohl sie tatsächlich "sinnlos" geworden ist (Berechnungen sind abgeschlossen, Daten werden nicht mehr benötigt, aber es gibt keine Ausstiegsbedingung). Ähnlich wie bei Speicherlecks, aber für Ausführungsstränge. Dies ist kritisch für Go — eine hohe Last kann zu Ressourcenerschöpfung führen.

Problem:

Im Gegensatz zu anderen Sprachen, in denen die direkte Steuerung von Threads oft zu deren manuellem Stoppen führt, werden in Go Goroutinen leicht gestartet, aber nicht immer korrekt beendet. Ein häufiger Fehler: Die Hauptlogik ist abgeschlossen, aber die Goroutine ist "eingefroren" — sie wartet auf Daten von einem geschlossenen Kanal oder wird überhaupt nicht das Signal erhalten.

Lösung:

Um Lecks zu verhindern, werden kontrollierende Konstrukte verwendet: Kontext, Schließen von Kanälen, Signalisierungsvariablen. Es ist wichtig, die Ausstiegswege aus jeder Goroutine im Voraus zu planen und defer zur Bereinigung zu verwenden. Beispiel:

func worker(ctx context.Context, jobs <-chan int, results chan<- int) {
    for {
        select {
        case <-ctx.Done():
            return
        case job, ok := <-jobs:
            if !ok {
                return
            }
            results <- job * 2
        }
    }
}

Schlüsselmerkmale:

Kontrollieren Sie den gesamten Lebenszyklus der Goroutine
Verwenden Sie den Kontext für kontrolliertes Beenden
Schließen Sie Kanäle nach der Verwendung

Fangfragen.

Kann man einfach den Kanal schließen, um die Goroutine zu stoppen?

Nicht immer. Wenn im Select andere Fälle vorhanden sind oder keine Überprüfung des Schließens über ok erfolgt, kann die Goroutine "hängen bleiben".

val, ok := <-ch
if !ok { return } // So ist es korrekter

Was passiert, wenn man vergisst, context.Done im Select zu behandeln?

Die Goroutine wird niemals erfahren, dass die Abbruchanfrage erfolgt ist — sie bleibt "ewig". Das ist der direkte Weg zu einem Leak.

Kann man Leaks mit der Go-Laufzeit erkennen?

Es gibt kein standardmäßiges Werkzeug zur Verfolgung von Leaks. Es ist notwendig, die Anzahl der aktiven Goroutinen über runtime.NumGoroutine zu überwachen oder einen Leak-Detektor von Drittanbieterbibliotheken zu verwenden.

Typische Fehler und Antipatterns

Warten auf einen nicht existierenden oder blockierten Kanal
Starten von endlosen Goroutinen ohne Ausstiegswege
Inkonsistenz beim Schließen von Kanälen

Beispiel aus dem Leben

Negativer Fall

Im Push-Benachrichtigungssystem werden Goroutinen für jede eingehende Nachricht gestartet, aber es wird vergessen, diese beim Abbrechen des Kontexts oder Schließen des Kanals zu stoppen — Hunderte "toter" Goroutinen bleiben im Speicher hängen.

Vorteile:

Einfach zu starten, schnelles Prototyping

Nachteile:

Speicherwachstum
Verlangsamung des Planers

Positiver Fall

Die Arbeit der Goroutine wird über den Kontext gesteuert, auf der Ebene der Geschäftlogik wird der Ausstieg aus dem Select überprüft, nach erfolgreicher Übermittlung/Bearbeitung wird der Kanal geschlossen.