Antwort

In Go ist ein Kanal ein Mittel zur Übertragung von Daten zwischen Goroutinen mit Synchronisation. Es gibt:

• Unpufferter Kanal — blockiert den Sender, bis die Daten von einer anderen Goroutine empfangen werden.
• Gepufferter Kanal — enthält einen internen Puffer fester Größe. Der Sender blockiert nur, wenn der Puffer vollständig ist.

Unpufferte Kanäle sind praktisch, wenn Synchronisation entscheidend ist und garantiert werden muss, dass Sender und Empfänger an derselben Stelle im Code treffen. Gepufferte Kanäle eignen sich zur Datenübertragung „mit Spielraum“ — zur Organisation von Warteschlangen, Workern, asynchronen Aufgaben.

Beispiel:

func main() {
    ch := make(chan int) // unpufferter Kanal
    go func() {
        ch <- 42 // blockiert, bis ein Empfänger vorhanden ist
    }()
    fmt.Println(<-ch)

    bufch := make(chan int, 2) // gepufferter Kanal mit 2 Elementen
    bufch <- 1 // blockiert nicht
    bufch <- 2 // blockiert nicht
    // der nächste Sendebefehl wird blockiert, wenn es keine Leser gibt
}

Fangfrage

Kann ein gepufferter Kanal als Ersatz für eine Warteschlange zwischen Dutzenden von Produzenten und Konsumenten ohne zusätzliche Synchronisation dienen?

Oft wird mit „ja“ geantwortet. In der Tat nur, wenn die Garantien für die Reihenfolge nicht wichtig sind und Nachrichten nicht verloren gehen. Bei mehreren Lesern/Schreibern können Wettlaufsituationen und Datenverlust auftreten, weshalb eine Synchronisationskontrolle trotzdem nötig ist (Worker-Pools, Mutexe, Kontexte zum Schließen von Kanälen).

Beispiele für echte Fehler aufgrund mangelnden Wissens über die Feinheiten des Themas

---

Geschichte

Im Logging-Prozess verwendeten Programmierer einen gepufferten Kanal der Länge 1000 zur Übertragung von Ereignissen zwischen Parser und Aggregator. Beim Stoppen des Dienstes wurde vergessen, den Kanal zu schließen, und ein Teil der Ereignisse wurde „verloren“ — die Worker beendeten sich, bevor der gesamte Puffer verarbeitet wurde. Es wurde behoben durch das explizite Schließen von Kanälen und das Blockieren bis zur vollständigen Entladung.

---

Geschichte

Bei dem Versuch, eine Mutex-Warteschlange durch einen gepufferten Kanal in einem verteilten Dienst zu ersetzen, wurde die Situation von „hängenden“ Sendern nicht berücksichtigt: Bei vollem Puffer führte die Sendeblockierung letztendlich zu einer Verlangsamung des gesamten Systems, zu Timeouts und die Schnittstelle begann zu „laggen“. Nach einer Analyse wurde ein Teil der Synchronisation durch Bedingungsvariablen zurückgeführt.

---

Geschichte

Im Telemetrie-Modul wurde ein unpufferter Kanal für das Logging von Fehlern zwischen dem Modul und dem Konsumenten verwendet. Aufgrund zufälliger Verzögerungen in der Verarbeitung wurde der Schreiber blockiert, und innerhalb einer Minute bildete sich eine Warteschlange von Hunderttausenden von Daten in Goroutinen — es trat ein „out of goroutines“ auf. Es wurde behoben, indem der unpufferte Kanal durch einen gepufferten Kanal und einen asynchronen Worker zur leeren Warteschlange ersetzt wurde.