Une course de données se produit quand deux ou plus de goroutines accèdent à la même mémoire simultanément, au moins un accès est une écriture, et il n'y a aucune synchronisation entre eux. Le résultat est un comportement indéfini — données corrompues, plantages ou résultats incorrects qui apparaissent de manière intermittente. Go fournit un détecteur de courses intégré pour les trouver.
// ❌ DATA RACE — multiple goroutines write the same variable without synchronization
func main() {
counter := 0
var wg sync.WaitGroup
for i := 0; i < 1000; i++ {
wg.Add(1)
go func() {
defer wg.Done()
counter++ // RACE: read-modify-write, multiple goroutines at once
}()
}
wg.Wait()
fmt.Println(counter) // often NOT 1000 — updates are lost due to the race
}
counter++ est une lecture-modification-écriture (trois étapes). Quand les goroutines s'entrelacent, les mises à jour s'écrasent mutuellement, donc le décompte final est imprévisible. Le résultat varie entre les exécutions — la nature insidieuse des courses.
go run -race main.go # run with race detection enabled
go test -race ./... # run tests with the race detector (best practice in CI)
go build -race # build a race-detecting binary
The race detector reports each race it observes:
==================
WARNING: DATA RACE
Write at 0x... by goroutine 7: main.main.func1() main.go:12
Previous read at 0x... by goroutine 6: ...
==================
Le détecteur de courses instrumente les accès mémoire au runtime et rapporte exactement où une course se produit (les accès conflictuels et leurs goroutines/lignes). C'est l'un des outils les plus précieux de Go — exécutez vos tests avec -race régulièrement (particulièrement en CI) pour attraper les courses avant la production.
// Fix 1: protect with a mutex
var mu sync.Mutex
mu.Lock(); counter++; mu.Unlock()
// Fix 2: use atomic operations (lock-free, for simple values)
import "sync/atomic"
var counter int64
atomic.AddInt64(&counter, 1) // atomic — no race
// Fix 3: don't share — use channels to pass ownership
results := make(chan int)
// each goroutine sends its result; one goroutine aggregates
Les corrections sont les outils de synchronisation : un mutex pour sérialiser l'accès, des opérations atomiques pour les compteurs simples, ou des channels pour éviter de partager la mémoire.
✗ NON-DETERMINISTIC — may work in testing, fail in production (timing-dependent)
✗ Hard to reproduce — depends on goroutine scheduling, load, hardware
✗ UNDEFINED behavior — not just wrong values; can corrupt data or crash
✗ Often invisible without the race detector — no error, just subtly wrong results
Les courses de données sont parmi les bugs les plus dangereux et les plus difficiles à déboguer en Go concurrent — et la conception axée sur la concurrence de Go en fait un risque réel.
Elles sont insidieuses parce qu'elles sont non-déterministes : du code avec une course peut passer tous les tests et fonctionner correctement sous charge légère, puis échouer de manière intermittente en production sous charge concurrente, produisant des données corrompues, des résultats incorrects ou des plantages qui sont presque impossibles à reproduire.
Comprendre la définition précise (accès concurrent à la mémoire partagée avec au moins une écriture et aucune synchronisation), reconnaître que même du code innocent comme counter++ a une course, et connaître les corrections (mutex, atomique, channels) est essentiel pour écrire du Go concurrent correct.
De manière critique, le détecteur de courses (-race) intégré de Go est l'outil indispensable — exécuter les tests avec lui (idéalement en CI) attrape les courses qui seraient autrement invisibles.
Maîtriser la détection et la prévention des courses est une compétence fondamentale pour le Go concurrent de niveau production et l'un des sujets avancés les plus importants du langage, puisque la correction de la concurrence est exactement où les programmes Go échouent le plus souvent.