Duomenų lenktynės atsiranda, kai du ar daugiau goroutines vienu metu pasiekia tą patį atminties darbinį, bent vienas prieiga yra rašymas, ir tarp jų nėra sinchronizacijos. Rezultatas yra neapibrėžtas elgesys — sugadinti duomenys, programos kritimas arba neteisingi rezultatai, kurie pasirodo netaisyklingai. Go turi integruotą lenktynių detektorių, skirta juos rasti.
// ❌ 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++ yra skaityti-keisti-rašyti (trys žingsniai). Kai goroutines persidengia, atnaujinimai perrašo vienas kitą, todėl galutinis skaičius yra nenuspėjamas. Rezultatas skiriasi tarp paleidimų — tai yra lenktynių subtrus pobūdis.
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: ...
==================
Lenktynių detektorius instrumentuoja atminties prieigos paleidimo metu ir tiksliai praneša, kur atsiranda lenktynės (konfliktines prieigos ir jų goroutines/eilutes). Tai vienas iš Go vertingiausių įrankių — reguliariai naudokite -race savo testams (ypač CI aplinkoje), kad aptiktumėte lenktynės prieš gamybą.
// 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
Taisymai — tai sinchronizacijos įrankiai: mutex seriyzuoti prieigai, atominės operacijos paprastiems skaitliams, arba kanalai, kad išvengti atminties dalinimosi.
✗ 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
Duomenų lenktynės yra tarp pavojingiausių ir sunkiausiai derinamo kūdikio lygičios Go — ir Go intensyvus lygiatetiškumą naudojantis dizainas juos daro tikra rizika.
Jos yra subtrios, nes yra nedeterministinės: kodas su lenktynemis gali praeiti visus testus ir gerai veikti esant mažam apkrovimui, tada staiga suktis gamyboje esant lygiatetiškam apkrovimui, gaminant sugadintus duomenis, neteisingus rezultatus arba kritimus, kurie yra beveik neįmanomi atkurti.
Supratimas apie tikslų apibrėžimą (lygiatetiška prieiga prie bendro atminties su bent vienu rašymu ir be sinchronizacijos), atpažinimas, kad net nekaltai atrodantis kodas kaip counter++ lenktyninkauja, ir žinojimas pataisų (mutex, atomic, kanalai) yra būtinas rašant teisingą lygiatetiškumą Go.
Kritiškai svarbų, Go integruotas lenktynių detektorius (-race) yra neperimamas įrankis — testų paleidimas su juo (idealiai CI) aptinka lenktynės, kurios kitaip būtų nematomos.
Lenktynių aptikimo ir prevencijos valdymas yra pagrindinė ištekliai gamybos kokybiško lygiatetiškumo Go ir vienas iš svarbiausių pažangių temų kalboje, nes lygiatetiškumo teisingumas yra tiksliai tai, kur Go programos dažniausiai žlunga.