Uma data race ocorre quando dois ou mais goroutines acessam a mesma memória concorrentemente, pelo menos um acesso é uma escrita, e não há sincronização entre eles. O resultado é um comportamento indefinido — dados corrompidos, crashes, ou resultados incorretos que aparecem intermitentemente. Go fornece um detector de race integrado para encontrá-las.
// ❌ 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++ é uma operação ler-modificar-escrever (três etapas). Quando os goroutines se intercalam, as atualizações sobrescrevem umas às outras, então a contagem final é imprevisível. O resultado varia entre execuções — a natureza insidiosa das 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: ...
==================
O detector de race instrumenta acessos à memória em tempo de execução e relata exatamente onde uma race acontece (os acessos conflitantes e seus goroutines/linhas). É uma das ferramentas mais valiosas do Go — execute seus testes com -race regularmente (especialmente em CI) para capturar races antes da produção.
// 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
As correções são as ferramentas de sincronização: um mutex para serializar o acesso, operações atomic para contadores simples, ou channels para evitar compartilhar memória completamente.
✗ 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 estão entre os bugs mais perigosos e mais difíceis de depurar em Go concorrente — e o design orientado para concorrência do Go as torna um risco real.
São insidiosas porque são não-determinísticas: código com uma race pode passar em todos os testes e funcionar bem sob carga leve, depois falhar intermitentemente em produção sob carga concorrente, produzindo dados corrompidos, resultados incorretos, ou crashes que são quase impossíveis de reproduzir.
Compreender a definição precisa (acesso concorrente à memória compartilhada com pelo menos uma escrita e nenhuma sincronização), reconhecer que até código inocente como counter++ tem race, e conhecer as correções (mutex, atomic, channels) é essencial para escrever Go concorrente correto.
Criticamente, o detector de race integrado do Go (-race) é a ferramenta indispensável — executar testes com ele (idealmente em CI) captura races que de outra forma seriam invisíveis.
Dominar a detecção e prevenção de races é uma habilidade fundamental para Go concorrente em nível de produção e um dos tópicos avançados mais importantes da linguagem, já que a corretude da concorrência é exatamente onde os programas Go mais frequentemente falham.