Risposta.

Storia della domanda: I canali sono uno dei concetti fondamentali del modello CSP in Go. Sono progettati per lo scambio di dati tra goroutine. Lavorare con i canali richiede particolare attenzione per evitare deadlock, perdite di memoria e panico durante la chiusura.

Problema: La chiusura e l'uso successivo dei canali porta spesso a panico (panic: send on closed channel). Lavorare con canali nil o tentare di leggere da un canale chiuso senza controllo può dare risultati inaspettati. Diverse goroutine possono scrivere e leggere simultaneamente in un canale, richiedendo una logica di ciclo di vita chiaramente definita.

Soluzione: Il canale deve sempre essere chiuso solo dalla parte che non scriverà più nel canale (di solito il produttore). Dopo la chiusura, è possibile leggere valori dal canale fino all'esaurimento, ma non scrivere — si verificherà un panic. È comodo controllare la chiusura tramite il secondo parametro restituito dal canale:

Esempio di codice:

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

Caratteristiche chiave:

• Il canale deve essere chiuso solo dove nessuno scrive più in esso.
• Leggere da un canale chiuso restituisce zero value (0 per int, "" per string) e false nel secondo parametro.
• Scrivere in un canale chiuso provoca panic.

Domande insidiose.

1. È necessario chiudere il canale se viene letto solo da una goroutine e nessun altro aspetta valori aggiuntivi?

Risposta: Non è necessario chiudere il canale se nessuno aspetta la sua chiusura tramite range. Ma se viene utilizzato un ciclo for v := range ch — sì, il canale deve essere chiuso, altrimenti il ciclo non terminerà.

2. Cosa succede se leggo da un canale chiuso?

Risposta: I valori verranno restituiti fino a quando non si esaurisce il buffer, poi — zero value e segnale false. È sicuro leggere fino alla fine dopo la chiusura.

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

3. Chi deve chiudere il canale: il lettore o lo scrittore?

Risposta: Sempre "lo scrittore" (chi invia valori e sa quando il lavoro è finito). "Il lettore" non deve chiudere il canale per evitare condizioni di gara.

Errori comuni e anti-pattern

• Chiusura del canale non da "scrittore", ma da "ricevitore".
• Tentativo di scrivere in un canale chiuso, che porta a panic.
• Organizzazione errata della gestione delle condizioni finali tramite range su un canale non chiuso.
• Dimenticanza di chiudere i canali, causando blocchi permanenti nei lettori (deadlock).

Esempio dalla vita reale

Caso negativo

Nell'applicazione diverse goroutine scrivono in un canale, una legge. Qualcuno ha chiuso il canale nel lettore, e un'altra goroutine ha cercato di inviare ancora — panic.

Pro: Logica d'interazione relativamente semplice. Contro: Impossibilità di prevedere il momento della chiusura, panico, condizioni di gara.

Caso positivo

Lo scrittore tiene traccia di tutte le goroutine, utilizza sync.WaitGroup, chiude il canale solo dopo che tutte le operazioni di scrittura sono terminate. Il lettore termina correttamente il ciclo range dopo la chiusura del canale e gestisce gli errori in modo sicuro.

Pro: Sincronizzazione corretta, nessuna perdita e deadlock, comportamento prevedibile. Contro: Logica leggermente più complessa, necessità di completare esplicitamente tutte le operazioni.