Ein Data Race tritt auf, wenn zwei oder mehr Goroutinen auf denselben Speicher gleichzeitig zugreifen, mindestens ein Zugriff ein Schreiben ist und keine Synchronisierung zwischen ihnen existiert. Das Ergebnis ist undefiniertes Verhalten — beschädigte Daten, Abstürze oder falsche Ergebnisse, die intermittierend auftreten. Go bietet einen integrierten Race Detector, um diese zu finden.
// ❌ 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++ ist ein Read-Modify-Write (drei Schritte). Wenn Goroutinen verzahnt werden, überschreiben Aktualisierungen einander, daher ist die endgültige Anzahl unvorhersehbar. Das Ergebnis variiert zwischen den Ausführungen — die heimtückische Natur von 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: ...
==================
Der Race Detector instrumentiert Speicherzugriffe zur Laufzeit und meldet genau, wo ein Race auftritt (die in Konflikt stehenden Zugriffe und ihre Goroutines/Zeilen). Es ist eines von Gos wertvollsten Werkzeugen — führen Sie Ihre Tests regelmäßig mit -race aus (besonders in CI), um Races vor der Produktion zu erkennen.
// 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
Die Fixes sind die Synchronisierungswerkzeuge: ein Mutex, um Zugriff zu serialisieren, Atomic-Operationen für einfache Zähler, oder Channels, um gemeinsamen Speicher ganz zu vermeiden.
✗ 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 gehören zu den gefährlichsten und am schwierigsten zu debuggenden Bugs in nebenläufigem Go — und Gos concurrency-lastiges Design macht sie zu einem echten Risiko.
Sie sind heimtückisch, weil sie nicht-deterministisch sind: Code mit einem Race kann alle Tests bestehen und unter leichter Last gut funktionieren, dann aber in der Produktion unter Concurrency-Last intermittierend fehlschlagen und beschädigte Daten, falsche Ergebnisse oder Abstürze produzieren, die fast unmöglich zu reproduzieren sind.
Das Verständnis der genauen Definition (gleichzeitiger Zugriff auf gemeinsamen Speicher mit mindestens einem Schreiben und ohne Synchronisierung), das Erkennen, dass selbst unschuldiger aussehender Code wie counter++ raced, und das Wissen um die Fixes (Mutex, Atomic, Channels) ist unerlässlich, um korrektes nebenläufiges Go zu schreiben.
Kritisch ist, dass Gos integrierten Race Detector (-race) das unverzichtbare Werkzeug ist — Tests damit auszuführen (idealerweise in CI) fängt Races ab, die sonst unsichtbar sind.
Die Beherrschung von Race-Erkennung und -Prävention ist eine grundlegende Fähigkeit für produktionsreifes nebenläufiges Go und eines der wichtigsten fortgeschrittenen Themen in der Sprache, da Concurrency-Korrektheit genau dort ist, wo Go-Programme am häufigsten fehlschlagen.