Antwort.

Goroutinen sind leichte Ausführungsströme, die in die Architektur von Go von den ersten Versionen an integriert wurden, um effektive Parallelität zu erreichen. Historisch gesehen entstand die Idee des Lightweight-Threads aus dem Versuch, die Kosten von Systemthreads zu umgehen, sowie aus dem hohen Bedarf an skalierbaren serverseitigen Anwendungen. Go wurde ursprünglich als Sprache für Server- und Netzwerksysteme konzipiert, in denen Millionen von Aufgaben parallel verarbeitet werden müssen.

Problem: Konkurrenz kann schnell zu Race Conditions, Deadlocks und einem Anstieg des Speicherverbrauchs führen, wenn der Lebenszyklus von Goroutinen nicht kontrolliert, ihre Planung nicht berücksichtigt und ihr Abschluss nicht verwaltet wird.

Lösung: Goroutinen werden mit dem Schlüsselwort go gestartet. Die Ausführung von Goroutinen wird vom Go-Scheduler geplant, der ein M:N-Modell verwendet (M Betriebssystem-Threads bedienen N Goroutinen der Go-Sprache). Zur Verwaltung des Lebenszyklus werden Kanäle, WaitGroup, Kontexte und die Steuerung des Schließens von Kanälen verwendet.

Beispielcode:

package main
import ("fmt"; "time")

func worker(id int) {
    fmt.Printf("Worker %d gestartet
", id)
    time.Sleep(time.Second)
    fmt.Printf("Worker %d fertig
", id)
}

func main() {
    for i := 1; i <= 3; i++ {
        go worker(i)
    }
    time.Sleep(2 * time.Second)
}

Wesentliche Merkmale:

Sofortige und kostengünstige Erstellung von Goroutinen (um Zehntausende von Malen günstiger als Betriebssystem-Threads).
Direkte Interaktion über Kanäle, Gewährleistung von Synchronisation und Datenaustausch.
Notwendigkeit der manuellen Kontrolle über den Abschluss der Arbeit (welche Goroutinen warten, wer sie unterbricht, wie die Benachrichtigung über den Stopp erfolgt).

Fangfragen.

Wenn die Goroutine in der main nicht explizit gewartet wird, wird sie immer ausgeführt?

Nein, die Ausführung von main bringt das Programm zum Abschluss — der Prozess wird unabhängig vom Status von untergeordneten Goroutinen beendet, und nicht alle Aufgaben werden ausgeführt.

Ist der Start von go func(...) aus einer Schleife eine Garantie dafür, dass jede Goroutine ihren eigenen Wert der Schleifenvariablen erhält?

Nein, es tritt ein Problem beim Erfassen der Schleifenvariable auf, Goroutinen können mit demselben Wert des Slice/der Variablen arbeiten. Man muss die Variable kopieren, indem man sie beispielsweise als Argument übergibt:

for i := 0; i < 3; i++ {
    go func(n int) {
        fmt.Println(n)
    }(i)
}

Kann eine Goroutine den Go-Scheduler blockieren und verhindern, dass andere ausgeführt werden?

Ja, wenn sie eine unendliche oder sehr rechenintensive Schleife ohne Umschaltpunkte (zum Beispiel ohne Aufrufe von Zeitfunktionen oder yield) startet, kann sie den Betriebssystem-Thread festhalten — obwohl dies der Ideologie von Go über "kooperative Parallelität" widerspricht. Ein Beispiel für eine rechenintensive Funktion ohne Blockaden:

func busy() {
    for {
        // Es gibt keine Erwartungen oder blockierenden Aufrufe
    }
}

Typische Fehler und Anti-Pattern

Starten von Goroutinen ohne Kontrolle über ihren Abschluss
Erfassen von Schleifenvariablen ohne deren Übertragung an anonyme Funktionen
Überlastung des Systems aufgrund von "leaky goroutines" (Leck nicht abschließend Goroutinen)
Ignorieren von Synchronisationsfehlern beim Austausch über Kanäle

Beispiel aus dem Leben

Negativer Fall

In einem Mikrodienst wird periodisch eine Goroutine zum Lesen aus der Datenbank gestartet, aber vergessen, sie bei Abbruch der Anfrage zu beenden. Dadurch bleiben "hängende" Goroutinen zurück, die im Laufe der Zeit den gesamten Arbeitsspeicher verbrauchen.

Vorteile:

Hohe Startgeschwindigkeit
Einfachheit der Skalierung

Nachteile:

Speicherleck
Anstieg der Antwortzeit
Unvorhersehbares Ende

Positiver Fall

Der Kontext wird verwendet, um die Stornierung von Aufgaben zu steuern, WaitGroup — um den Abschluss aller Goroutinen vor dem Stopp der Anwendung zu verwalten, und Kanäle — um einen korrekten Datenaustausch zwischen den Ausführenden sicherzustellen.