Goroutinen, Channels und das sync-Package: Nebenläufigkeit in Go im Überblick

Worum es geht

Die Sprachspezifikation definiert eine go-Anweisung als das Starten eines Funktionsaufrufs als unabhängigen, nebenläufigen Kontrollfluss innerhalb desselben Adressraums; der Aufrufer wartet nicht darauf. Die Laufzeitumgebung multiplext Goroutinen auf Betriebssystem-Threads mit kleinen, wachsenden Stacks, sodass sich ein Server eine Goroutine pro Verbindung leisten kann. Channels sind typisierte Leitungen, die mit make(chan T, capacity) erzeugt werden: Bei Kapazität null wird ein Senden erst abgeschlossen, wenn ein Empfänger bereit ist; sonst blockiert das Senden nur, wenn der Puffer voll ist. select wartet gleichzeitig auf mehrere Channel-Operationen, close signalisiert, dass keine weiteren Werte mehr kommen, und range leert einen Channel, bis er geschlossen wird. Das sync-Package stellt Mutex, RWMutex, WaitGroup (deren in Go 1.25 hinzugefügte Methode Go eine Goroutine startet und verfolgt), Once sowie die Hilfsfunktionen OnceFunc/OnceValue (Go 1.21) zur Verfügung; seine Dokumentation besagt, dass Synchronisierung auf höherer Ebene besser über Channels und Kommunikation erfolgt.

Warum es wichtig ist

Entwicklerinnen und Entwickler, die von CPython unter dem GIL oder von Node.js kommen, haben nie erlebt, dass zwei Codepfade im selben Moment eine Map verändern; in Go kann das geschehen. Das Memory Model definiert einen Data Race als einen Schreibzugriff auf eine Speicherstelle, der gleichzeitig mit einem weiteren Lese- oder Schreibzugriff darauf erfolgt, sofern nicht alle Zugriffe atomar sind; eine Implementierung darf den Race melden und das Programm anhalten, und Races auf Interface-Werten, Maps, Slices und Strings können zu beliebiger Speicherkorruption führen. Ein race-behafteter Zähler verliert lediglich Inkremente, und niemand bemerkt es.

So wird es angewendet

• Die Primitive nach der Form des Problems wählen: Channels für die Übergabe von Arbeit oder Ergebnissen zwischen Stufen, einen Mutex für ein kleines Stück gemeinsam genutzten Zustands, eine WaitGroup für das Warten, bis ein Stapel abgeschlossen ist.
• Nebenläufigkeit begrenzen: einen gepufferten Channel als Semaphor verwenden oder einen festen Pool von Worker-Goroutinen, die von einem Channel lesen, statt einer Goroutine pro Element einer unbegrenzten Schleife.
• Für jede Goroutine die Austrittsbedingung explizit machen: wer den Channel schliesst, welcher Kontext sie abbricht. Eine Goroutine, die für immer an einem Channel blockiert, den niemand liest, ist ein Leck.
• Tests mit go test -race ausführen; die Dokumentation des Race-Detektors hält fest, dass er nur Races findet, die zur Laufzeit tatsächlich auftreten, sodass die nebenläufigen Pfade auch durchlaufen werden müssen.
• sync-Werte niemals kopieren; die Dokumentation des Packages hält fest, dass Werte, die dessen Typen enthalten, nicht kopiert werden sollten.

Stolpersteine

Sowohl das Senden auf einen geschlossenen Channel als auch das zweimalige Schliessen eines Channels lösen einen Panic aus; nur der Sender sollte schliessen. Ein nil-Channel blockiert für immer, was in select nützlich ist, um einen Fall zu deaktivieren, und überall sonst ein Fehler ist. WaitGroup.Add muss vor dem Start der Goroutine erfolgen, nicht in ihr. Ungepufferte Channels koppeln das Timing von Sender und Empfänger; Puffer verbergen Backpressure, bis sie voll sind.