Sebuah data race terjadi ketika dua atau lebih goroutine mengakses memori yang sama secara bersamaan, setidaknya satu akses adalah penulisan, dan tidak ada sinkronisasi di antara mereka. Hasilnya adalah perilaku yang tidak terdefinisi — data yang rusak, crash, atau hasil yang salah yang muncul secara intermiten. Go menyediakan race detector bawaan untuk menemukannya.
// ❌ 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++ adalah read-modify-write (tiga langkah). Ketika goroutine saling selang-seling, pembaruan menimpa satu sama lain, sehingga hitungan akhir tidak dapat diprediksi. Hasilnya bervariasi antar eksekusi — sifat insidious dari race.
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: ...
==================
Race detector menginstrumentasi akses memori pada saat runtime dan melaporkan dengan tepat di mana race terjadi (akses yang bertentangan dan goroutine/baris mereka). Ini adalah salah satu alat paling berharga Go — jalankan tes Anda dengan -race secara teratur (terutama di CI) untuk menangkap race sebelum 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
Perbaikannya adalah alat sinkronisasi: mutex untuk serialisasi akses, operasi atomic untuk counter sederhana, atau channel untuk menghindari berbagi memori sama sekali.
✗ 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 race adalah di antara bug yang paling berbahaya dan paling sulit di-debug dalam concurrent Go — dan desain concurrent-heavy Go membuat mereka menjadi risiko nyata.
Mereka bersifat insidious karena non-deterministik: kode dengan race mungkin lolos semua tes dan bekerja baik di bawah beban ringan, lalu gagal secara intermiten di production di bawah beban concurrent, menghasilkan data yang rusak, hasil yang salah, atau crash yang hampir mustahil untuk direproduksi.
Memahami definisi yang tepat (akses concurrent ke memori bersama dengan setidaknya satu penulisan dan tidak ada sinkronisasi), mengenali bahwa bahkan kode yang terlihat innocent seperti counter++ race, dan mengetahui perbaikannya (mutex, atomic, channel) sangat penting untuk menulis concurrent Go yang benar.
Secara kritis, race detector bawaan Go (-race) adalah alat yang tidak dapat digantikan — menjalankan tes dengannya (idealnya di CI) menangkap race yang sebaliknya tidak terlihat.
Menguasai deteksi dan pencegahan race adalah keterampilan fundamental untuk concurrent Go grade production dan salah satu topik advanced paling penting dalam bahasa, karena kebenaran concurrency adalah justru di mana program Go paling sering gagal.