Et data race opstår, når to eller flere goroutines tilgår samme hukommelse samtidigt, mindst ét tilgang er en skrivning, og der er ingen synkronisering mellem dem. Resultatet er udefineret adfærd — korrupt data, nedbrud eller forkerte resultater, der optræder sporadisk. Go tilbyder en indbygget race detektor til at finde dem.
// ❌ 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++ er læs-modificer-skriv (tre trin). Når goroutines interleaver, overskriver opdateringer hinanden, så det endelige tælleresultat er uforudsigelig. Resultatet varierer mellem kørsler — races' fordækte natur.
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: ...
==================
Race detektoren instrumenterer hukommelsestilgange ved runtime og rapporterer præcis, hvor et race sker (de konfliktende tilgange og deres goroutines/linjer). Det er et af Gos mest værdifulde værktøjer — kør dine tests med -race regelmæssigt (især i CI) for at fange races før produktion.
// 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
Udbedringerne er synkroniseringsværktøjerne: en mutex til at serialisere adgang, atomic operationer til enkle tællere, eller channels til at undgå hukommelsdeling helt.
✗ 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 er blandt de mest farlige og sværeste fejl at fejlsøge i concurrent Go — og Gos design med meget concurrency gør dem til en reel risiko.
De er fordækte, fordi de er ikke-deterministiske: kode med et race kan består alle tests og fungere fint under let belastning, men fejler sporadisk i produktion under concurrent belastning, hvilket producerer korrupt data, forkerte resultater eller nedbrud, som næsten er umulige at genskabe.
At forstå den præcise definition (concurrent adgang til delt hukommelse med mindst en skrivning og ingen synkronisering), genkende, at selv uskyldigt udseende kode som counter++ racer, og kende løsningerne (mutex, atomic, channels) er essentielt for at skrive korrekt concurrent Go.
Kritisk set er Gos indbyggede race detektor (-race) det uundværlige værktøj — at køre tests med det (ideelt i CI) fanger races, som ellers er usynlige.
At mestre race detektion og prævention er en grundlæggende færdighed for production-grade concurrent Go og et af de vigtigste avancerede emner i sproget, da concurrency korrekthed er præcis det område, hvor Go-programmer oftest fejler.