Réponse.

Contexte de la question :
Les canaux sont l'un des concepts fondamentaux du modèle CSP en Go. Ils sont conçus pour l'échange de données entre goroutines. Travailler avec des canaux nécessite une attention particulière pour éviter les deadlocks, les fuites et les paniques lors de la fermeture.

Problème :
La fermeture et l'utilisation ultérieure des canaux entraînent souvent une panique (panic : send on closed channel). Travailler avec des canaux nuls ou tenter de lire à partir d'un canal fermé sans vérification peut donner des résultats inattendus. Différentes goroutines peuvent lire et écrire simultanément dans un même canal, ce qui nécessite une logique de cycle de vie clairement définie.

Solution :
Un canal doit toujours être fermé uniquement du côté où personne ne l'écrira plus (généralement le producteur). Après la fermeture, il est possible de lire des valeurs depuis le canal jusqu'à son épuisement, mais il n'est pas possible d'écrire — cela entraînera une panique. La vérification de la fermeture est facilement effectuée en utilisant le deuxième paramètre retourné par le canal :

Exemple de code :

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

Caractéristiques clés :

• Le canal doit être fermé uniquement là où personne d'autre n'écrit plus dedans.
• Lire à partir d'un canal fermé renvoie une valeur nulle (0 pour int, "" pour string) et false dans le deuxième paramètre.
• Écrire dans un canal fermé — panique.

Questions pièges.

1. Faut-il fermer le canal si une seule goroutine le lit et que personne d'autre n'attend des valeurs supplémentaires ?

Réponse : Il n'est pas nécessaire de fermer le canal si personne ne l'attend via range. Mais si l'on utilise la boucle for v := range ch — oui, il est impératif de fermer le canal, sinon la boucle ne se terminera pas.

2. Que se passe-t-il si l'on lit à partir d'un canal fermé ?

Réponse : Des valeurs seront retournées tant que le tampon n'est pas épuisé, ensuite — valeur nulle et indicateur false. Il est sûr de lire jusqu'à la fin après la fermeture.

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

3. Qui doit fermer le canal : le lecteur ou l'écrivain ?

Réponse : Toujours "l'écrivain" (celui qui envoie des valeurs et sait quand le travail est terminé). Le "lecteur" ne doit pas fermer le canal pour éviter les races.

Erreurs courantes et anti-modèles

• Fermeture du canal par le "récepteur" plutôt que par l"émetteur".
• Essai d'écriture dans un canal fermé, ce qui entraîne une panique.
• Mauvaise organisation du traitement des conditions terminales via range sur un canal non fermé.
• Oublier de fermer les canaux, ce qui bloque éternellement les boucles de lecture (deadlock).

Exemple de la vie

Cas négatif

Dans une application, plusieurs goroutines écrivent dans un canal, une seul lit. Quelqu'un ferme le canal dans le lecteur, tandis qu'une autre goroutine essaie encore d'envoyer — panique.

Avantages : Logique d'interaction relativement simple.
Inconvénients : Impossibilité de prédire le moment de la fermeture, paniques, conditions de course.

Cas positif

L'écrivain garde une trace de toutes les goroutines, utilise sync.WaitGroup, ferme le canal uniquement après la fin de tous les écrivains. Le lecteur termine correctement la boucle range après la fermeture du canal, traite les erreurs de manière sécurisée.

Avantages : Synchronisation correcte, pas de fuites et de deadlocks, comportement prévisible.
Inconvénients : Logique légèrement plus complexe, nécessité de terminer explicitement tous les travaux.