Goroutines et channels

Concurrence vs parallélisme

Imaginez un cuisinier seul dans une cuisine. Il peut préparer la salade pendant que l'eau bout et que le poulet est au four. Il ne fait qu'une chose à la fois, mais il jongle entre plusieurs tâches. C'est la concurrence.

Maintenant imaginez trois cuisiniers qui préparent chacun un plat en même temps. C'est le parallélisme.

Go excelle dans les deux. Et il rend la concurrence ridiculement simple avec un seul mot-clé : go.

Les goroutines : la concurrence en un mot

Une goroutine est une fonction qui s'exécute en arrière-plan. Pour la lancer, ajoutez go devant l'appel :

func afficher(msg string) {
    for i := 0; i < 3; i++ {
        fmt.Println(msg)
        time.Sleep(100 * time.Millisecond)
    }
}

func main() {
    go afficher("goroutine")  // S'exécute en arrière-plan
    afficher("main")          // S'exécute au premier plan
}

Les deux fonctions s'exécutent en même temps. La sortie peut varier à chaque exécution :

main
goroutine
goroutine
main
main
goroutine

Une goroutine coûte environ 2 Ko de mémoire. Un thread système en coûte 1 Mo. Vous pouvez créer des millions de goroutines sans problème : c'est comme ça que Go gère des milliers de connexions simultanées.

Les channels : communiquer entre goroutines

Les goroutines travaillent en parallèle, mais comment échangent-elles des données ? Via des channels : des tuyaux typés :

func calculer(ch chan int) {
    resultat := 42 * 2
    ch <- resultat  // Envoyer dans le channel
}

func main() {
    ch := make(chan int)       // Créer un channel d'entiers
    go calculer(ch)            // Lancer la goroutine
    resultat := <-ch           // Recevoir du channel (bloquant)
    fmt.Println(resultat)      // 84
}

L'opérateur <- fonctionne dans les deux sens :

• ch <- valeur : envoyer une valeur dans le channel
• valeur := <-ch : recevoir une valeur du channel

La réception est bloquante : le programme attend jusqu'à ce qu'une valeur arrive. Pas besoin de mutex ou de verrous compliqués.

Par défaut, un channel est non bufferisé : l'envoi attend qu'un récepteur soit prêt (remise en main propre). Avec make(chan int, 3), on crée un channel bufferisé : l'envoi ne bloque pas tant que le buffer n'est pas plein. Pratique pour découpler producteur et consommateur ; on s'en resservira plus loin.

Le proverbe de Go : "Ne communiquez pas en partageant de la mémoire. Partagez de la mémoire en communiquant."

select : écouter plusieurs channels

select permet d'attendre sur plusieurs channels en même temps, comme un switch pour les channels :

func main() {
    ch1 := make(chan string)
    ch2 := make(chan string)

    go func() {
        time.Sleep(100 * time.Millisecond)
        ch1 <- "résultat 1"
    }()
    go func() {
        time.Sleep(200 * time.Millisecond)
        ch2 <- "résultat 2"
    }()

    select {
    case msg := <-ch1:
        fmt.Println("Reçu de ch1:", msg)
    case msg := <-ch2:
        fmt.Println("Reçu de ch2:", msg)
    }
}

select exécute le premier channel qui est prêt. C'est la base des serveurs web performants et des systèmes temps réel.

Deux précisions importantes. Si plusieurs cas sont prêts en même temps, select en choisit un au hasard (il n'y a pas de priorité du haut vers le bas). Et un cas default rend le select non bloquant : il s'exécute immédiatement si aucun channel n'est prêt, au lieu d'attendre.

sync.WaitGroup : attendre toutes les goroutines

Comment savoir quand toutes vos goroutines ont terminé ? Avec sync.WaitGroup :

func main() {
    var wg sync.WaitGroup

    for i := 1; i <= 3; i++ {
        wg.Add(1)  // +1 goroutine à attendre
        go func(n int) {
            defer wg.Done()  // -1 quand terminé
            fmt.Printf("Tâche %d terminée\n", n)
        }(i)
    }

    wg.Wait()  // Attendre que toutes soient terminées
    fmt.Println("Tout est fini !")
}

Trois méthodes : Add(n) ajoute n tâches, Done() signale qu'une tâche est terminée, Wait() bloque jusqu'à ce que le compteur atteigne zéro.

Le piège n°1 : les data races

Dès que deux goroutines touchent la même variable en même temps et qu'au moins l'une écrit, vous avez une data race. Le résultat devient imprévisible. Exemple typique : mille goroutines qui incrémentent un compteur partagé (on utilise le WaitGroup qu'on vient de voir pour les attendre).

func main() {
    compteur := 0
    var wg sync.WaitGroup
    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            compteur++   // data race : plusieurs goroutines écrivent
        }()
    }
    wg.Wait()
    fmt.Println(compteur)  // Presque jamais 1000 !
}

On attend 1000. En réalité on obtient 973, 988, un nombre différent à chaque exécution. Pourquoi ? Parce que compteur++ n'est pas une seule opération : c'est lire la valeur, ajouter 1, puis réécrire. Deux goroutines lisent 41 en même temps, ajoutent 1, et réécrivent 42 toutes les deux : une incrémentation est perdue.

Go fournit un détecteur de course intégré. Lancez votre programme avec le flag -race :

go run -race main.go

Il instrumente le code et signale précisément quelles goroutines accèdent à quelle variable sans synchronisation, numéros de ligne à l'appui. Réflexe à prendre : dès qu'un comportement vous semble non déterministe, relancez avec -race. Il a un coût (temps et mémoire multipliés par ~5 à 10), donc on l'active en développement et dans les tests, jamais en production. Les règles exactes de ce qui est garanti (la relation happens-before) sont définies dans le Go Memory Model officiel.

Mutex ou channel ? relier la donnée à sa primitive

La data race précédente se corrige de deux façons, selon votre intention : protéger un état partagé, ou transférer une donnée d'une goroutine à une autre. Le vrai piège n'est pas la syntaxe, c'est de savoir quelle primitive pour quelle donnée.

Pour protéger un état, on pose un verrou : sync.Mutex. Une seule goroutine à la fois tient le verrou, les autres attendent leur tour :

func main() {
    compteur := 0
    var mu sync.Mutex
    var wg sync.WaitGroup
    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            mu.Lock()
            compteur++       // un seul accès à la fois
            mu.Unlock()
        }()
    }
    wg.Wait()
    fmt.Println(compteur)  // 1000, à chaque exécution
}

L'autre façon, côté channel : confier le compteur à une seule goroutine et lui envoyer les +1 par un channel. La donnée n'est jamais partagée, donc aucun verrou n'est nécessaire :

func main() {
    incr := make(chan int)
    done := make(chan int)
    go func() {            // seule cette goroutine touche le compteur
        compteur := 0
        for range incr {
            compteur++
        }
        done <- compteur
    }()
    var wg sync.WaitGroup
    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() { defer wg.Done(); incr <- 1 }()
    }
    wg.Wait()
    close(incr)            // plus d'envois : la boucle range se termine
    fmt.Println(<-done)   // 1000
}

À vous d'essayer

Reprenez l'exemple goroutine + channel et exécutez-le directement :

package main

import "fmt"

func calculer(ch chan int) {
    resultat := 42 * 2
    ch <- resultat
}

func main() {
    ch := make(chan int)
    go calculer(ch)
    resultat := <-ch
    fmt.Println("Résultat reçu du channel :", resultat)
}