En datakappløp oppstår når to eller flere goroutiner får tilgang til det samme minnet samtidig, minst én tilgang er en skriving, og det er ingen synkronisering mellom dem. Resultatet er udefinert oppførsel — korrupt data, krasj, eller feil resultater som dukker opp uforutsigbart. Go tilbyr en innebygd race detector for å finne 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 lese-modifiser-skriv (tre trinn). Når goroutiner vikles inn, overskrives oppdateringer, så den endelige tellingen er uforutsigbar. Resultatet varierer mellom kjøringer — den insinuerende naturen av kappløp.
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 detectoren instrumenterer minneaksesser ved kjøretid og rapporterer nøyaktig hvor en kappløp skjer (de motstridende tilgangene og deres goroutiner/linjer). Det er ett av Gos mest verdifulle verktøy — kjør testene dine med -race regelmessig (spesielt i CI) for å fange kappløp før produksjon.
// 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
Reparasjonene er synkroniseringsverktøyene: en mutex for å serialisere tilgang, atomic operasjoner for enkle tellere, eller channels for å unngå minnedelingalltogether.
✗ 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
Datakappløp er blant de farligste og vanskeligste å debugge feilene i concurrent Go — og Gos concurrency-tunge design gjør dem til en reell risiko.
De er insinuerende fordi de er ikke-deterministiske: kode med et kappløp kan bestå alle tester og fungere fint under lett belastning, og deretter mislykkes uforutsigbart i produksjon under concurrent belastning, produserer korrupt data, feil resultater, eller krasj som er nesten umulig å gjenskape.
Å forstå den presise definisjonen (concurrent tilgang til delt minne med minst én skriving og ingen synkronisering), gjenkjenne at selv uskyldigt utseende kode som counter++ har kappløp, og kjenne til reparasjonene (mutex, atomic, channels) er essensielt for å skrive korrekt concurrent Go.
Kritisk, Gos innebygde race detector (-race) er det uunnværlige verktøyet — å kjøre tester med det (ideelt i CI) fanger kappløp som ellers er usynlige.
Å mestre race-deteksjon og -forebygging er en fundamental ferdighet for produksjonsklasse concurrent Go og ett av de viktigste avanserte emnene i språket, siden concurrency-korrekthet er akkurat hvor Go-programmer oftest mislykkes.