A data race occurs when two or more goroutines access the same memory concurrently, at least one access is a write, and there's no synchronization between them. The result is undefined behavior — corrupted data, crashes, or wrong results that appear intermittently. Go provides a built-in race detector to find them.
// ❌ 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++ is read-modify-write (three steps). When goroutines interleave, updates overwrite each other, so the final count is unpredictable. The result varies between runs — the insidious nature of races.
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: ...
==================
The race detector instruments memory accesses at runtime and reports exactly where a race happens (the conflicting accesses and their goroutines/lines). It's one of Go's most valuable tools — run your tests with -race regularly (especially in CI) to catch races before production.
// 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
The fixes are the synchronization tools: a mutex to serialize access, atomic operations for simple counters, or channels to avoid sharing memory altogether.
✗ 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
Data races are among the most dangerous and hardest-to-debug bugs in concurrent Go — and Go's concurrency-heavy design makes them a real risk.
They're insidious because they're non-deterministic: code with a race may pass all tests and work fine under light load, then fail intermittently in production under concurrent load, producing corrupted data, wrong results, or crashes that are nearly impossible to reproduce.
Understanding the precise definition (concurrent access to shared memory with at least one write and no synchronization), recognizing that even innocent-looking code like counter++ races, and knowing the fixes (mutex, atomic, channels) is essential for writing correct concurrent Go.
Critically, Go's built-in race detector (-race) is the indispensable tool — running tests with it (ideally in CI) catches races that are otherwise invisible.
Mastering race detection and prevention is a fundamental skill for production-grade concurrent Go and one of the most important advanced topics in the language, since concurrency correctness is exactly where Go programs most often fail.