Een data race treedt op wanneer twee of meer goroutines gelijktijdig dezelfde geheugenlocatie benaderen, minstens één benadering een schrijfoperatie is, en er geen synchronisatie tussen hen plaatsvindt. Het resultaat is ongedefinieerd gedrag — beschadigde gegevens, crashes of foute resultaten die sporadisch optreden. Go biedt een ingebouwde race detector om deze te vinden.
// ❌ 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++ is een read-modify-write operatie (drie stappen). Wanneer goroutines verweven, overschrijven updates elkaar, dus het eindresultaat is onvoorspelbaar. Het resultaat varieert tussen uitvoeringen — de sluimerende aard van races.
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: ...
==================
De race detector instrumenteert geheugentoegang in runtime en rapporteert precies waar een race optreedt (de conflicterende toegangen en hun goroutines/regels). Het is een van Go's meest waardevolle tools — voer je tests regelmatig uit met -race (vooral in CI) om races vóór productie op te sporen.
// 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
De fixes zijn synchronisatietools: een mutex om toegang te serialiseren, atomic operaties voor eenvoudige tellers, of channels om geheel niet met gedeeld geheugen te werken.
✗ 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
Data races behoren tot de gevaarlijkste en moeilijkst op te sporen bugs in concurrent Go — en Go's concurrency-intensieve ontwerp maakt ze een reëel risico.
Ze zijn sluipend omdat ze niet-deterministisch zijn: code met een race kan alle tests doorstaan en prima werken onder lichte belasting, maar vervolgens sporadisch mislukken in productie onder gelijktijdige belasting, wat beschadigde gegevens, foute resultaten of crashes veroorzaakt die bijna onmogelijk te reproduceren zijn.
Begrip van de precieze definitie (gelijktijdige toegang tot gedeeld geheugen met minstens één schrijfoperatie en geen synchronisatie), herkenning dat zelfs onschuldig uitziende code als counter++ races heeft, en kennis van de fixes (mutex, atomic, channels) is essentieel voor het schrijven van correct concurrent Go.
Kritiek is Go's ingebouwde race detector (-race) het onmisbare tool — het uitvoeren van tests ermee (bij voorkeur in CI) vangt races die anders onzichtbaar blijven.
Beheersing van race detection en preventie is een fundamentele vaardigheid voor productie-grade concurrent Go en een van de meest belangrijke geavanceerde onderwerpen in de taal, omdat concurrency correctness exact is waar Go-programma's het vaakst mislukken.