Antwoord.

Achtergrond van de vraag: Kanalen zijn een van de fundamentele concepten van het CSP-model in Go. Ze zijn bedoeld voor gegevensuitwisseling tussen goroutines. Werken met kanalen vereist bijzondere voorzichtigheid om deadlocks, lekken en panics bij het sluiten te voorkomen.

Probleem: Het sluiten en verder gebruik van kanalen leidt vaak tot panics (panic: send on closed channel). Werken met nil-kanalen of proberen te lezen uit een gesloten kanaal zonder controle kan onverwachte resultaten opleveren. Verschillende goroutines kunnen gelijktijdig naar en uit dezelfde kanaal schrijven en lezen, wat een duidelijk beschreven levenscycluslogica vereist.

Oplossing: Een kanaal moet altijd alleen worden gesloten vanaf de zijde waar niemand meer naar het kanaal schrijft (meestal de producent). Na sluiting kunnen waarden uit het kanaal worden gelezen totdat het leeg is, maar schrijven is niet toegestaan — er zal een panic optreden. Het is handig om het sluiten te controleren via de tweede teruggegeven parameter uit het kanaal:

Voorbeeldcode:

ch := make(chan int)
go func() {
    for i := 0; i < 5; i++ {
        ch <- i
    }
    close(ch)
}()
for v := range ch {
    fmt.Println(v)
}

Belangrijke kenmerken:

• Een kanaal moet alleen worden gesloten waar niemand meer naar schrijft.
• Lezen uit een gesloten kanaal geeft zero value (0 voor int, "" voor string) en false in de tweede parameter.
• Schrijven naar een gesloten kanaal — panic.

Misleidende vragen.

1. Moet je een kanaal sluiten als het alleen door één goroutine wordt gelezen en niemand anders op extra waarden wacht?

Antwoord: Het is niet nodig om het kanaal te sluiten als niemand wacht op de sluiting via range. Maar als je de loop for v := range ch gebruikt — ja, het kanaal moet absoluut worden gesloten, anders stopt de loop niet.

2. Wat gebeurt er als je uit een gesloten kanaal leest?

Antwoord: Waarden worden geretourneerd zolang de buffer niet leeg is, daarna — zero value en het teken false. Het is veilig om tot het einde te lezen na sluiting.

ch := make(chan int, 1)
ch <- 42
close(ch)
v, ok := <-ch // v = 42, ok = true
v, ok = <-ch  // v = 0, ok = false

3. Wie moet het kanaal sluiten: de lezer of de schrijver?

Antwoord: Altijd de "schrijver" (degene die waarden verzendt en weet wanneer het werk is voltooid). De "lezer" moet het kanaal niet sluiten om race-voorwaarden te voorkomen.

Typische fouten en antipatterns

• Het sluiten van het kanaal door de "ontvanger" in plaats van de "zendende".
• Proberen te schrijven naar een gesloten kanaal, wat leidt tot panic.
• Onjuiste organisatie van het afhandelen van eindvoorwaarden via range over een niet gesloten kanaal.
• Het vergeten van het sluiten van kanalen, waardoor lezer-lussen voor altijd worden geblokkeerd (deadlock).

Voorbeeld uit het leven

Negatieve geval

In de applicatie schrijven verschillende goroutines naar één kanaal, één leest. Iemand sloot het kanaal in de lezer, terwijl een andere goroutine nog probeerde te verzenden — panic.

Voordelen: Voorwaardelijk eenvoudige interactielogica. Nadelen: Onmogelijk om het sluitmoment te voorspellen, panics, race-conditions.

Positieve geval

De schrijver houdt rekening met alle goroutines, gebruikt sync.WaitGroup en sluit het kanaal alleen na voltooiing van alle schrijvers. De lezer beëindigt de range-loop correct na sluiting van het kanaal en verwerkt fouten veilig.

Voordelen: Correcte synchronisatie, geen lekken en deadlock, voorspelbaar gedrag. Nadelen: Iets complexere logica, het is nodig om alle taken expliciet te beëindigen.