Data race происходит, когда два или более goroutine обращаются к одной и той же памяти одновременно, хотя бы одно обращение является записью, и между ними отсутствует синхронизация. Результат — неопределённое поведение: повреждение данных, крахи или неправильные результаты, которые проявляются нерегулярно. Go предоставляет встроенный детектор гонок, чтобы их находить.
// ❌ 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++ — это операция чтение-изменение-запись (три этапа). Когда goroutine чередуются, обновления перезаписывают друг друга, поэтому финальное значение счётчика непредсказуемо. Результат различается между запусками — таков коварный характер гонок.
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: ...
==================
Детектор гонок инструментирует обращения к памяти во время выполнения и точно сообщает, где произошла гонка (конфликтующие обращения и их goroutine/строки). Это один из самых ценных инструментов Go — регулярно запускайте тесты с флагом -race (особенно в CI), чтобы поймать гонки до 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
Исправления используют инструменты синхронизации: мьютекс для сериализации доступа, атомарные операции для простых счётчиков или каналы, чтобы вообще избежать совместного использования памяти.
✗ 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 — это одни из самых опасных и сложнейших в отладке ошибок в конкурентном Go — и ориентированный на конкурентность дизайн Go делает их реальной угрозой.
Они коварны, потому что недетерминированы: код с гонкой может пройти все тесты и работать хорошо при лёгкой нагрузке, а затем в production при конкурентной нагрузке неожиданно сломаться, повредив данные, дав неправильные результаты или упав крахом — всё это практически невозможно воспроизвести.
Понимание точного определения (конкурентный доступ к общей памяти с хотя бы одной записью и без синхронизации), узнавание того, что даже безобидный код вроде counter++ гоняется, и знание исправлений (мьютекс, атомарные операции, каналы) — всё это необходимо для написания корректного конкурентного Go.
Критически важно, что у Go есть встроенный детектор гонок (-race) — это незаменимый инструмент, и запуск тестов с ним (в идеале в CI) ловит гонки, которые иначе остались бы невидимыми.
Овладение обнаружением и предотвращением гонок — фундаментальный навык для production-grade конкурентного Go и один из самых важных продвинутых разделов языка, так как именно в корректности конкурентности Go-программы чаще всего дают сбой.