Una data race si verifica quando due o più goroutine accedono alla stessa memoria contemporaneamente, almeno un accesso è una scrittura, e non c'è sincronizzazione tra loro. Il risultato è un comportamento indefinito — corruzione dei dati, crash o risultati errati che appaiono in modo intermittente. Go fornisce un race detector incorporato per trovarle.
// ❌ 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++ è un'operazione read-modify-write (tre passi). Quando le goroutine si intrecciano, gli aggiornamenti si sovrascrivono a vicenda, quindi il conteggio finale è imprevedibile. Il risultato varia tra le esecuzioni — la natura insidiosa delle race.
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: ...
==================
Il race detector strumenta gli accessi alla memoria a runtime e segnala esattamente dove si verifica una race (gli accessi in conflitto e le loro goroutine/righe). È uno degli strumenti più preziosi di Go — esegui i tuoi test con -race regolarmente (soprattutto in CI) per catturare le race prima della produzione.
// 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
Le correzioni sono gli strumenti di sincronizzazione: un mutex per serializzare gli accessi, operazioni atomic per contatori semplici, o channel per evitare del tutto la condivisione della memoria.
✗ 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
Le data race sono tra i bug più pericolosi e difficili da debuggare in Go concorrente — e il design orientato alla concorrenza di Go le rende un rischio reale.
Sono insidiose perché sono non-deterministiche: il codice con una race può passare tutti i test e funzionare bene sotto carico leggero, poi fallire in modo intermittente in produzione sotto carico concorrente, producendo corruzione dei dati, risultati errati o crash che sono quasi impossibili da riprodurre.
Comprendere la definizione precisa (accesso concorrente a memoria condivisa con almeno una scrittura e nessuna sincronizzazione), riconoscere che anche codice apparentemente innocente come counter++ ha race, e conoscere le correzioni (mutex, atomic, channel) è essenziale per scrivere Go concorrente corretto.
Criticamente, il race detector incorporato di Go (-race) è lo strumento indispensabile — eseguire i test con esso (idealmente in CI) cattura le race che altrimenti sarebbero invisibili.
Padroneggiare il rilevamento e la prevenzione delle race è un'abilità fondamentale per Go concorrente di livello produttivo ed è uno degli argomenti avanzati più importanti del linguaggio, poiché la correttezza della concorrenza è esattamente dove i programmi Go più spesso falliscono.