Una carrera de datos ocurre cuando dos o más gorrutinas acceden a la misma memoria concurrentemente, al menos un acceso es una escritura, y no hay sincronización entre ellas. El resultado es un comportamiento indefinido — datos corruptos, bloqueos o resultados incorrectos que aparecen intermitentemente. Go proporciona un detector de carreras incorporado para encontrarlas.
// ❌ 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++ es una operación lectura-modificación-escritura (tres pasos). Cuando las gorrutinas se entrelazan, las actualizaciones se sobrescriben mutuamente, por lo que el conteo final es impredecible. El resultado varía entre ejecuciones — la naturaleza insidiosa de las carreras.
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: ...
==================
El detector de carreras instrumenta los accesos a memoria en tiempo de ejecución e informa exactamente dónde ocurre una carrera (los accesos conflictivos y sus gorrutinas/líneas). Es una de las herramientas más valiosas de Go — ejecuta tus pruebas con -race regularmente (especialmente en CI) para detectar carreras antes de la producción.
// 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
Las correcciones son las herramientas de sincronización: un mutex para serializar el acceso, operaciones atómicas para contadores simples, o canales para evitar compartir memoria en absoluto.
✗ 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
Las carreras de datos están entre los errores más peligrosos y difíciles de depurar en Go concurrente — y el diseño intensivo en concurrencia de Go las hace un riesgo real.
Son insidiosas porque son no determinísticas: el código con una carrera puede pasar todas las pruebas y funcionar bien bajo carga ligera, luego fallar intermitentemente en producción bajo carga concurrente, produciendo datos corruptos, resultados incorrectos o bloqueos que son casi imposibles de reproducir.
Comprender la definición precisa (acceso concurrente a memoria compartida con al menos una escritura y sin sincronización), reconocer que incluso código aparentemente inocuo como counter++ tiene carreras, y conocer las soluciones (mutex, atómicas, canales) es esencial para escribir Go concurrente correcto.
Críticamente, el detector de carreras incorporado de Go (-race) es la herramienta indispensable — ejecutar pruebas con él (idealmente en CI) detecta carreras que de otro modo serían invisibles.
Dominar la detección y prevención de carreras es una habilidad fundamental para Go concurrente de grado de producción y uno de los temas más importantes avanzados del lenguaje, ya que la corrección de la concurrencia es exactamente donde los programas Go suelen fallar con más frecuencia.