O cursă de date apare când doi sau mai mulți goroutines accesează aceeași memorie concurent, cel puțin un acces este o scriere, și nu există sincronizare între ei. Rezultatul este comportament nedefinit — date corupte, prăbușiri sau rezultate greșite care apar intermitent. Go oferă un detector de curs încorporat pentru a le găsi.
// ❌ 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++ este citire-modificare-scriere (trei pași). Când goroutines se intercalează, actualizările se suprascriau între ele, deci numărătorul final este impredictibil. Rezultatul variază între execuții — natura insidioasă a curselor.
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: ...
==================
Detectorul de curse instrumentează accesele la memorie la runtime și raportează exact unde apare o cursă (accesele conflictuale și goroutines/liniile lor). Este unul dintre cele mai valoroase instrumente ale Go — rulează testele tale cu -race în mod regulat (mai ales în CI) pentru a prinde cursele înainte de producție.
// 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
Corecțiile sunt instrumentele de sincronizare: un mutex pentru a serializa accesul, operații atomic pentru numărătoare simple, sau canale pentru a evita complet partajarea memoriei.
✗ 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
Cursele de date sunt printre cele mai periculoase și greu de debuggat erori în Go concurent — și designul plin de concurență al Go le face un risc real.
Sunt insidioase pentru că sunt nedeterministe: codul cu o cursă poate trece toate testele și funcționa bine sub sarcină ușoară, apoi să se defecteze intermitent în producție sub sarcină concurentă, producând date corupte, rezultate greșite sau prăbușiri care sunt aproape imposibil de reprodus.
Înțelegerea definiției precise (acces concurent la memorie partajată cu cel puțin o scriere și fără sincronizare), recunoașterea că chiar și codul aparent inofensiv cum ar fi counter++ are curse, și cunoașterea corecțiilor (mutex, atomic, canale) este esențială pentru scrierea unui Go concurent corect.
Critic, detectorul de curse încorporat al Go (-race) este instrumentul indispensabil — rularea testelor cu el (ideal în CI) prinde cursele care altfel sunt invizibile.
Stăpânirea detectării și prevenirii curselor este o abilitate fundamentală pentru Go concurent la nivel de producție și unul dintre cele mai importante subiecte avansate din limbaj, deoarece corectitudinea concurenței este exact locul unde programele Go eșuează cel mai des.