Az adatverseny akkor fordul elő, amikor kettő vagy több goroutine egyidejűleg fér hozzá az ugyanahhoz a memóriához, legalább az egyik hozzáférés írás, és nincs szinkronizáció közöttük. Az eredmény nem definiált viselkedés — adatsérülés, összeomlás vagy rossz eredmények, amelyek időnként megjelennek. A Go beépített race detektort biztosít az ezek megtalálásához.
// ❌ 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
}
A counter++ read-modify-write (három lépés). Amikor a goroutinek egymásba érnek, az írások felülírják egymást, így a végső szám kiszámíthatatlan. Az eredmény változik az egyes futások között — az adatversenyek ravasz természete.
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: ...
==================
A race detektor a memóriahozzáféréseket futásidőben instrumentálja és pontosan jelentést készít arról, hol történt az adatverseny (az ütköző hozzáférések és azok goroutine-jei/sorai). Ez a Go egyik legértékesebb eszköze — rendszeresen futtassa tesztjeit a -race jelzővel (különösen a CI-ben), hogy a versenyzéseket az élesítés előtt elkapja.
// 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
A javítások a szinkronizációs eszközök: egy mutex a hozzáférés szerializálásához, atomic műveletek az egyszerű számlálókhoz, vagy csatornák a memóriamegosztás teljes elkerüléséhez.
✗ 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
Az adatversenyek a párhuzamos Go-ban a legveszélyesebbek és a legnehezebben debugolható hibák közül — és a Go párhuzamosság-orientált kialakítása valódi kockázattá teszi őket.
Ravaszak, mert nem determinisztikusak: az adatversenyeket tartalmazó kód átmehet az összes teszten és jól működhet alacsony terhelésnél, majd termékeléssé válva, párhuzamos terhelésnél időnként meghibásodhat, adatsérülést, rossz eredményeket vagy olyan összeomlásokat okozva, amelyeket szinte lehetetlen reprodukálni.
A pontos definíció megértése (megosztott memóriához való egyidejű hozzáférés legalább egy írással és szinkronizáció nélkül), annak felismerése, hogy még az ártatlannak tűnő kód, mint a counter++ is versenyez, és a javítások ismerete (mutex, atomic, csatornák) elengedhetetlen a helyes párhuzamos Go írásához.
Kritikusan fontos, hogy a Go beépített race detektora (-race) elengedhetetlen eszköz — ha a teszteket futtatja vele (ideálisan a CI-ben), az adatversenyeket érzékelj, amelyek egyébként láthatatlanok.
A versenyzésdetektálás és -megelőzés elsajátítása alapvető készség a termékelési szintű párhuzamos Go-hoz és az egyik legfontosabb speciális témakör a nyelvben, mivel a párhuzamossági helyesség pontosan az, ahol a Go-programok leggyakrabban meghibásodnak.