La Concurrence en Go : Goroutines, Canaux et Mutex

Bienvenue dans cette leçon dédiée à la concurrence en Go, un pilier essentiel pour quiconque souhaite maîtriser le développement backend avec ce langage. Dans le cadre de notre cours "Maîtrisez Go pour le Backend : Construisez des APIs Performantes et Scalables", comprendre et appliquer les principes de la concurrence est non seulement un avantage, mais une nécessité pour créer des services robustes, réactifs et efficaces.

Introduction : Pourquoi la Concurrence en Backend ?

Dans le monde des applications backend, la capacité à gérer plusieurs tâches simultanément est fondamentale. Une API doit pouvoir répondre à des milliers de requêtes entrantes sans bloquer, interagir avec des bases de données, des systèmes de messagerie ou d'autres microservices, et effectuer des traitements lourds, le tout de manière fluide. C'est là que la concurrence entre en jeu.

Go a été conçu dès le départ avec la concurrence à l'esprit, offrant des primitives légères et puissantes qui simplifient grandement le développement de systèmes concurrents. Contrairement à de nombreux autres langages où la concurrence peut être complexe et sujette aux erreurs, Go propose une approche élégante et idiomatique, souvent résumée par la philosophie : "Don't communicate by sharing memory; share memory by communicating." (Ne communiquez pas en partageant de la mémoire ; partagez de la mémoire en communiquant.)

Cette leçon explorera les trois pierres angulaires de la concurrence en Go : les Goroutines, les Canaux et les Mutex (verrous), et comment les utiliser efficacement pour construire des APIs performantes et scalables.

1. Les Goroutines : Les Fils d'Exécution Légers de Go

Qu'est-ce qu'une Goroutine ?

Une goroutine est une fonction ou une méthode exécutée simultanément avec d'autres goroutines. On peut les considérer comme des "threads" très légers et gérés par le runtime Go, plutôt que par le système d'exploitation.

Légèreté : Les goroutines sont incroyablement légères, nécessitant seulement quelques kilo-octets de pile de mémoire (qui peut croître ou décroître dynamiquement). Il est courant d'avoir des milliers, voire des millions, de goroutines actives dans une seule application Go.
Multiplexage : Le runtime Go multiplexe les goroutines sur un nombre inférieur de threads du système d'exploitation. Cela signifie que le scheduler Go décide quand une goroutine doit s'exécuter, plutôt que de laisser le système d'exploitation gérer les threads, ce qui est plus efficace.
Simplicité : Créer une goroutine est aussi simple que de préfixer un appel de fonction par le mot-clé go.

Créer et Utiliser une Goroutine

Pour lancer une fonction comme une goroutine, il suffit d'utiliser le mot-clé go devant l'appel de fonction :

package main

import (
	"fmt"
	"time"
)

func saluer(nom string) {
	fmt.Printf("Bonjour, %s, depuis une goroutine!\n", nom)
}

func main() {
	fmt.Println("Début du programme principal.")

	// Lance la fonction saluer comme une goroutine
	go saluer("Alice")
	go saluer("Bob")

	// Sans cette attente, le programme principal se terminerait
	// avant que les goroutines n'aient eu le temps de s'exécuter.
	time.Sleep(100 * time.Millisecond) // Attente artificielle pour l'exemple

	fmt.Println("Fin du programme principal.")
}

Explication du code :

La fonction saluer est une fonction simple qui imprime un message.
Dans main, nous appelons go saluer("Alice") et go saluer("Bob"). Cela lance deux nouvelles goroutines qui exécuteront saluer en parallèle avec la goroutine principale (main).
La ligne time.Sleep(100 * time.Millisecond) est cruciale pour cet exemple. Sans elle, la goroutine principale se terminerait immédiatement après avoir lancé les goroutines saluer. Comme le programme principal se termine, toutes les goroutines qu'il a lancées sont également arrêtées, et vous ne verriez peut-être pas les messages des goroutines saluer. Dans une application réelle, les goroutines interagiraient généralement avec la goroutine principale via des canaux (voir section suivante) ou continueraient d'exécuter un service (comme un serveur HTTP) sans nécessiter d'attente explicite.

Goroutines et APIs Backend

En backend, les goroutines sont utilisées pour :

Traiter les requêtes concurrentes : Chaque requête HTTP entrante peut être gérée par une nouvelle goroutine.
Effectuer des opérations en arrière-plan : Envoyer des emails, traiter des images, logger des événements, etc., sans bloquer la réponse à l'utilisateur.
Gérer des connexions persistantes : Pour des WebSockets ou des services de streaming, chaque connexion peut être servie par une goroutine dédiée.

2. Les Canaux : Communiquer en Toute Sécurité

Si les goroutines sont les "travailleurs" de la concurrence en Go, les canaux sont les "tuyaux" sécurisés qui leur permettent de communiquer et de se synchroniser.

Qu'est-ce qu'un Canal ?

Un canal (en anglais channel) est un conduit typé à travers lequel vous pouvez envoyer et recevoir des valeurs avec un opérateur de canal (<-). C'est le moyen idiomatique de Go pour permettre aux goroutines d'échanger des données.

Typés : Un canal ne peut transporter qu'un certain type de données (ex: chan int, chan string, chan MyStruct).
Sécurisés : Les opérations d'envoi et de réception sur un canal sont atomiques et garantissent une synchronisation correcte, évitant les race conditions (conditions de concurrence) qui peuvent survenir lors du partage direct de la mémoire.
Blocage par défaut : Par défaut, un envoi sur un canal se bloque jusqu'à ce qu'un récepteur soit prêt. De même, une réception se bloque jusqu'à ce qu'un émetteur envoie une valeur. C'est ce qui permet la synchronisation.

Déclaration et Utilisation de Canaux

Pour créer un canal, utilisez la fonction make :

ch := make(chan int) // Crée un canal d'entiers non-buffered

Envoyer une valeur sur un canal :

ch <- 42 // Envoie la valeur 42 sur le canal ch

Recevoir une valeur d'un canal :

val := <-ch // Reçoit une valeur du canal ch et l'assigne à val

Canaux Non-Bufferisés vs. Bufferisés

Canaux Non-Bufferisés (Unbuffered Channels) :
- Créés avec make(chan Type).
- Les envois et les réceptions sont synchrones.
- Un envoi bloque jusqu'à ce qu'un récepteur soit prêt à recevoir.
- Une réception bloque jusqu'à ce qu'un émetteur envoie une valeur.
- Idéal pour la synchronisation ou pour s'assurer qu'une opération a été traitée.
Canaux Bufferisés (Buffered Channels) :
- Créés avec make(chan Type, capacity).
- Ils ont une capacité interne (un buffer).
- Un envoi ne bloque que si le buffer est plein.
- Une réception ne bloque que si le buffer est vide.
- Utile pour décharger des tâches rapidement ou pour des pipelines de données.

Exemple de Canal Non-Bufferisé :

package main

import (
	"fmt"
	"time"
)

func producteur(data chan<- string) {
	fmt.Println("[Producteur] Début de la production...")
	time.Sleep(1 * time.Second) // Simule un travail
	data <- "Données importantes" // Bloque ici jusqu'à ce que le consommateur soit prêt
	fmt.Println("[Producteur] Données envoyées.")
}

func consommateur(data <-chan string) {
	fmt.Println("[Consommateur] Prêt à recevoir...")
	val := <-data // Bloque ici jusqu'à ce que le producteur envoie des données
	fmt.Printf("[Consommateur] Reçu : '%s'\n", val)
}

func main() {
	messages := make(chan string) // Canal non-bufferisé

	go producteur(messages)
	go consommateur(messages)

	// La goroutine principale doit attendre que les autres goroutines finissent leur travail
	// ou les bloquerait. Ici, nous utilisons une attente artificielle.
	time.Sleep(2 * time.Second)
	fmt.Println("Fin du programme principal.")
}

Explication du code :

Nous créons un canal messages de type string.
producteur envoie une chaîne sur messages. Cette opération data <- "Données importantes" bloquera jusqu'à ce que consommateur soit prêt à recevoir.
consommateur reçoit une chaîne de messages. Cette opération <-data bloquera jusqu'à ce que producteur envoie une chaîne.
L'ordre des messages dans la console reflétera cette synchronisation. Les goroutines se rencontrent (rendez-vous) au niveau du canal.

Fermeture de Canaux et `select`

Fermeture (close) : Un canal peut être fermé par l'émetteur pour indiquer qu'aucune autre valeur ne sera envoyée. La réception d'un canal fermé renvoie la valeur zéro du type du canal et un second booléen ok qui est false.

ch := make(chan int)
go func() {
    ch <- 1
    ch <- 2
    close(ch) // Ferme le canal après l'envoi de toutes les données
}()

for val := range ch { // Boucle sur le canal jusqu'à ce qu'il soit fermé
    fmt.Println(val)
}
// Ou manuellement:
val, ok := <-ch // ok sera false quand le canal est vide et fermé

select : La déclaration select permet d'attendre sur plusieurs opérations de communication de canaux. Elle bloque jusqu'à ce que l'une des communications soit prête, puis exécute le cas correspondant.

package main

import (
	"fmt"
	"time"
)

func main() {
	c1 := make(chan string)
	c2 := make(chan string)

	go func() {
		time.Sleep(1 * time.Second)
		c1 <- "un"
	}()
	go func() {
		time.Sleep(2 * time.Second)
		c2 <- "deux"
	}()

	// Attend les deux messages
	for i := 0; i < 2; i++ {
		select {
		case msg1 := <-c1:
			fmt.Println("reçu", msg1)
		case msg2 := <-c2:
			fmt.Println("reçu", msg2)
		case <-time.After(3 * time.Second): // Optionnel: timeout
			fmt.Println("timeout")
			return
		}
	}
}

select est essentiel pour les services backend qui doivent écouter sur plusieurs sources (requêtes, messages de file d'attente, signaux d'arrêt, etc.) simultanément.

3. Les Mutex : Protéger la Mémoire Partagée

Bien que la philosophie de Go soit de "partager la mémoire en communiquant", il existe des situations où le partage direct de la mémoire est inévitable ou plus approprié. Dans ces cas, il faut protéger les accès concurrents à cette mémoire partagée pour éviter les race conditions. C'est le rôle des Mutex (Mutual Exclusion) de Go.

Qu'est-ce qu'un Mutex ?

Un mutex est un verrou qui garantit qu'une seule goroutine à la fois peut accéder à une ressource partagée. Si une goroutine tente d'acquérir un verrou déjà détenu par une autre, elle se bloque jusqu'à ce que le verrou soit libéré.

Go fournit le type sync.Mutex pour les verrous exclusifs et sync.RWMutex pour les verrous lecture/écriture.

Utilisation de `sync.Mutex`

Les méthodes principales de sync.Mutex sont :

Lock() : Acquiert le verrou. Bloque si le verrou est déjà pris.
Unlock() : Relâche le verrou.

Il est crucial de toujours déverrouiller un mutex après l'avoir verrouillé, même en cas d'erreur. L'utilisation de defer est fortement recommandée pour cela.

Exemple de Race Condition et sa Résolution avec Mutex :

Considérons un compteur global qui est incrémenté par plusieurs goroutines. Sans protection, le résultat final est souvent incorrect en raison des race conditions.

package main

import (
	"fmt"
	"sync"
	"runtime"
)

var (
	compteur int
	// mu est un mutex pour protéger l'accès concurrentiel à 'compteur'
	mu sync.Mutex
)

func incrementer(wg *sync.WaitGroup) {
	defer wg.Done() // Indique que cette goroutine a terminé à la fin de la fonction

	// Verrouille l'accès au compteur
	mu.Lock()
	compteur++ // Opération critique : lecture, incrémentation, écriture
	mu.Unlock() // Déverrouille l'accès
}

func main() {
	runtime.GOMAXPROCS(runtime.NumCPU()) // Utilise tous les cœurs disponibles

	fmt.Println("Compteur initial:", compteur)

	var wg sync.WaitGroup // Utilisé pour attendre que toutes les goroutines terminent

	nombreDeGoroutines := 1000
	wg.Add(nombreDeGoroutines) // Indique combien de goroutines nous allons attendre

	for i := 0; i < nombreDeGoroutines; i++ {
		go incrementer(&wg)
	}

	wg.Wait() // Attend que toutes les goroutines dans le WaitGroup soient Done()

	fmt.Println("Compteur final:", compteur)
}

Explication du code :

Nous déclarons une variable compteur globale et un sync.Mutex appelé mu.
La fonction incrementer est lancée par plusieurs goroutines.
Sans mu.Lock() et mu.Unlock() : Si nous retirions ces lignes, plusieurs goroutines pourraient lire la valeur de compteur en même temps, l'incrémenter, puis écrire le résultat. Cela entraînerait des pertes d'incrémentations (ex: deux goroutines lisent 0, incrémentent à 1, écrivent 1. Au lieu de 2, le compteur est 1). Le résultat final serait probablement inférieur à 1000.
Avec mu.Lock() et mu.Unlock() : Chaque goroutine qui appelle incrementer doit d'abord acquérir le verrou mu. Si une autre goroutine le détient déjà, elle attendra. Une fois le verrou acquis, la goroutine incrémente compteur en toute sécurité, puis libère le verrou. Cela garantit que l'opération compteur++ est atomique et que le résultat final sera 1000.
sync.WaitGroup est utilisé pour s'assurer que la goroutine main attend que toutes les goroutines incrementer aient fini avant d'imprimer le résultat final.

`sync.RWMutex` : Mutex Lecture/Écriture

Pour les données qui sont lues beaucoup plus fréquemment qu'elles ne sont écrites, sync.RWMutex est plus performant.

RLock() : Acquiert un verrou en lecture. Plusieurs goroutines peuvent détenir ce verrou simultanément.
RUnlock() : Relâche un verrou en lecture.
Lock() : Acquiert un verrou en écriture. Ce verrou est exclusif ; il bloque tous les RLock() et Lock() concurrents.
Unlock() : Relâche un verrou en écriture.

4. Choisir le Bon Outil : Canaux ou Mutex ?

La question se pose souvent : quand utiliser des canaux et quand utiliser des mutex ?

Canaux (CSP - Communicating Sequential Processes) :
- Philosophie Go : "Ne communiquez pas en partageant de la mémoire ; partagez de la mémoire en communiquant."
- Quand l'utiliser :
  - Lorsque les goroutines doivent échanger des données ou se synchroniser pour un flux de travail.
  - Pour orchestrer des tâches (par exemple, un producteur envoyant des tâches à plusieurs consommateurs).
  - Pour signaler la fin d'une opération ou le début d'une autre.
  - Pour construire des pipelines de traitement de données.
- Avantages : Conduisent à un code plus clair et moins sujet aux erreurs de concurrence, car ils gèrent la synchronisation implicitement.
Mutex (Partage de Mémoire Explicite) :
- Philosophie traditionnelle : "Communiquez en partageant de la mémoire."
- Quand l'utiliser :
  - Lorsque plusieurs goroutines doivent modifier une structure de données partagée (ex: un compteur, un cache, une map) et qu'il n'y a pas de flux de communication naturel entre elles au-delà de l'accès à cette donnée.
  - Pour protéger l'accès à des ressources externes (fichiers, connexions réseau) qui ne sont pas naturellement adaptées à une communication par canal.
- Avantages : Peut être plus performant pour des accès très granulaires ou pour des structures de données complexes où la transformation en messages via canaux serait plus lourde.

Règle d'or : Si vous pouvez résoudre votre problème de concurrence avec des canaux, c'est généralement l'approche préférée et la plus idiomatique en Go. N'utilisez des mutex que lorsque le partage de mémoire est la solution la plus simple, logique ou performante pour votre cas d'usage spécifique, et soyez extrêmement rigoureux avec leur gestion (defer mu.Unlock()).

Conclusion

La concurrence est le cœur battant de Go, offrant des outils puissants et simples pour construire des applications backend performantes et scalables.

Les Goroutines vous permettent d'exécuter des milliers de tâches légères simultanément.
Les Canaux sont le moyen idiomatique et sûr pour ces goroutines de communiquer et de se synchroniser, en incarnant la philosophie "partager la mémoire en communiquant".
Les Mutex sont là pour protéger les accès à la mémoire partagée lorsque la communication par canal n'est pas l'approche la plus adaptée, bien qu'ils nécessitent une gestion attentive.

En maîtrisant ces trois concepts, vous serez en mesure de concevoir et d'implémenter des APIs qui peuvent gérer un trafic intense, effectuer des opérations complexes en arrière-plan, et exploiter pleinement les capacités des processeurs multi-cœurs. Entraînez-vous, expérimentez et n'oubliez jamais l'importance de la clarté et de la sûreté dans votre code concurrent.

La Concurrence en Go : Goroutines, Canaux et Mutex

Introduction : Pourquoi la Concurrence en Backend ?

1. Les Goroutines : Les Fils d'Exécution Légers de Go

Qu'est-ce qu'une Goroutine ?

Créer et Utiliser une Goroutine

Goroutines et APIs Backend

2. Les Canaux : Communiquer en Toute Sécurité

Qu'est-ce qu'un Canal ?

Déclaration et Utilisation de Canaux

Canaux Non-Bufferisés vs. Bufferisés

Fermeture de Canaux et select

3. Les Mutex : Protéger la Mémoire Partagée

Qu'est-ce qu'un Mutex ?

Utilisation de sync.Mutex

sync.RWMutex : Mutex Lecture/Écriture

4. Choisir le Bon Outil : Canaux ou Mutex ?

Conclusion

Fermeture de Canaux et `select`

Utilisation de `sync.Mutex`

`sync.RWMutex` : Mutex Lecture/Écriture