Goroutines, channels et le paquet sync : la concurrence en Go en bref

Ce que c'est

La spécification du langage définit une instruction go comme démarrant un appel de fonction en tant que fil de contrôle concurrent indépendant au sein du même espace d'adressage ; l'appelant n'attend pas son achèvement. Le runtime multiplexe les goroutines sur des threads du système d'exploitation avec des piles petites et extensibles, ce qui permet à un serveur de s'offrir une goroutine par connexion. Les channels sont des conduits typés créés avec make(chan T, capacity) : avec une capacité nulle, un envoi n'aboutit que lorsqu'un récepteur est prêt ; sinon, les envois ne bloquent que lorsque le tampon est plein. select attend simultanément sur plusieurs opérations de channel, close signale qu'aucune autre valeur ne viendra, et range vide un channel jusqu'à sa fermeture. Le paquet sync fournit Mutex, RWMutex, WaitGroup (dont la méthode Go, ajoutée en Go 1.25, démarre et suit une goroutine), Once ainsi que les fonctions utilitaires OnceFunc/OnceValue (Go 1.21) ; sa documentation indique qu'une synchronisation de plus haut niveau se fait mieux via les channels et la communication.

Pourquoi c'est important

Des ingénieurs venant de CPython sous le GIL ou de Node.js n'ont jamais vu deux chemins de code modifier une même map au même instant ; en Go, c'est possible. Le modèle mémoire définit une course de données comme une écriture à un emplacement mémoire se produisant en même temps qu'une autre lecture ou écriture de cet emplacement, sauf si tous les accès sont atomiques ; une implémentation peut signaler la course et interrompre le programme, et des courses sur des valeurs d'interface, des maps, des slices et des chaînes peuvent entraîner une corruption mémoire arbitraire. Un compteur soumis à une course perd simplement des incréments, sans que personne ne le remarque.

Comment l'appliquer

• Choisir la primitive selon la forme du problème : les channels pour transmettre du travail ou des résultats entre étapes, un mutex pour un petit état partagé, un WaitGroup pour attendre la fin d'un lot.
• Borner la concurrence : un channel avec tampon utilisé comme sémaphore, ou un pool fixe de goroutines travailleuses lisant depuis un seul channel, plutôt qu'une goroutine par élément d'une boucle non bornée.
• Rendre explicite la condition de sortie de chaque goroutine : qui ferme le channel, quel contexte l'annule. Une goroutine bloquée indéfiniment sur un channel que personne ne lit constitue une fuite.
• Exécuter les tests avec go test -race ; la documentation du détecteur de courses indique qu'il ne trouve que les courses qui se produisent réellement à l'exécution, ce qui suppose donc que les chemins concurrents soient effectivement exercés.
• Ne jamais copier des valeurs sync ; la documentation du paquet indique que les valeurs contenant ses types ne doivent pas être copiées.

Pièges

Envoyer sur un channel fermé et fermer un channel deux fois provoquent tous deux une panique ; seul l'émetteur devrait fermer le channel. Un channel nil bloque indéfiniment, ce qui est utile dans un select pour désactiver un cas, et constitue un bug partout ailleurs. WaitGroup.Add doit être appelé avant le démarrage de la goroutine, pas à l'intérieur de celle-ci. Les channels sans tampon couplent le timing de l'émetteur et du récepteur ; les tampons masquent la contre-pression jusqu'à ce qu'ils se remplissent.