ਇੱਕ data race ਉਦੋਂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਦੋ ਜਾਂ ਵਧੇਰੇ goroutines ਇੱਕੋ ਮੈਮੋਰੀ ਨੂੰ ਇੱਕ ਸਾਥ ਐਕਸੈਸ ਕਰਦੇ ਹਨ, ਘੱਟੋ-ਘੱਟ ਇੱਕ ਐਕਸੈਸ ਇੱਕ write ਹੈ, ਅਤੇ ਉਹਨਾਂ ਦੇ ਵਿਚਕਾਰ ਕੋਈ ਸਮਕਾਲੀਤਾ ਨਹੀਂ ਹੈ। ਨਤੀਜਾ ਅਪਰਿਭਾਸ਼ਿਤ ਵਿਹਾਰ ਹੈ — ਖਰਾਬ ਡਾਟਾ, ਕ੍ਰੈਸ਼, ਜਾਂ ਗਲਤ ਨਤੀਜੇ ਜੋ ਆਦੀ ਤੌਰ 'ਤੇ ਪ੍ਰਗਟ ਹੁੰਦੇ ਹਨ। Go ਇੱਕ ਬਿਲਟ-ਇਨ race detector ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।
// ❌ 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++ read-modify-write ਹੈ (ਤਿੰਨ ਪੜਾਅ)। ਜਦੋਂ goroutines ਵਿਚਕਾਰ ਹੁੰਦੇ ਹਨ, ਅਪਡੇਟਸ ਇੱਕ ਦੂਜੇ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰਦੇ ਹਨ, ਤਾਂ ਅੰਤਮ ਗਿਣਤੀ ਬਹੁ-ਅਨੁਮਾਨਯੋਗ ਹੈ। ਨਤੀਜਾ ਚਲਾਉਣ ਦੇ ਵਿਚਕਾਰ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ — ਰੇਸਾਂ ਦੀ ਖਤਰਨਾਕ ਪ੍ਰਕਿਰਤੀ।
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 ਰਨਟਾਈਮ ਤੇ ਮੈਮੋਰੀ ਐਕਸੈਸ ਨੂੰ ਇੰਸਟਰੂਮੇਂਟ ਕਰਦਾ ਹੈ ਅਤੇ ਬਿਲਕੁਲ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ ਕਿ ਰੇਸ ਕਿੱਥੇ ਹਿਸਾਬ ਹੈ (ਵਿਰੋਧਾਭਾਸ ਐਕਸੈਸ ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ goroutines/ਲਾਈਨਾਂ)। ਇਹ Go ਦੀਆਂ ਸਭ ਤੋਂ ਕੀਮਤੀ ਚੀਜ਼ਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ — ਆਪਣੀਆਂ ਪਰੀਖਿਆਵਾਂ ਨੂੰ -race ਦੇ ਨਾਲ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਚਲਾਓ (ਖਾਸ ਕਰ ਕੇ CI ਵਿੱਚ) ਪ੍ਰੋਡਕਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਰੇਸਾਂ ਨੂੰ ਫੜਨ ਲਈ।
// 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
ਫਿਕਸ ਸਮਕਾਲੀਤਾ ਦੀਆਂ ਚੀਜ਼ਾਂ ਹਨ: ਐਕਸੈਸ ਨੂੰ ਸਮ੍ਹਾਲਣ ਲਈ ਇੱਕ mutex, ਸਧਾਰਨ ਕਾਊਂਟਰਾਂ ਲਈ atomic ਓਪਰੇਸ਼ਨ, ਜਾਂ ਮੈਮੋਰੀ ਸ਼ੇਅਰ ਕਰਨ ਤੋਂ ਬਚਣ ਲਈ channels।
✗ 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 ਦੀ ਸਮਕਾਲੀਤਾ-ਭਾਰੀ ਡਿਜ਼ਾਈਨ ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਸੱਚਮੁੱਚ ਖਤਰਾ ਬਣਾਉਂਦੀ ਹੈ।
ਉਹ ਖਤਰਨਾਕ ਹਨ ਕਿਉਂਕਿ ਉਹ non-deterministic ਹਨ: ਇੱਕ ਰੇਸ ਵਾਲਾ ਕੋਡ ਸਾਰੀਆਂ ਪਰੀਖਿਆਵਾਂ ਨੂੰ ਪਾਸ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਹਲਕੇ ਲੋਡ ਦੇ ਤਹਿਤ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ, ਫਿਰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਸਮਕਾਲੀ ਲੋਡ ਦੇ ਤਹਿਤ ਅਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ, ਖਰਾਬ ਡਾਟਾ, ਗਲਤ ਨਤੀਜੇ, ਜਾਂ ਕ੍ਰੈਸ਼ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਦੁਬਾਰਾ ਬਣਾਉਣ ਲਈ ਲਗਭਗ ਅਸੰਭਵ ਹਨ।
ਸਟੀਕ ਪਰਿਭਾਸ਼ਾ ਨੂੰ ਸਮਝਣਾ (ਸ਼ੇਅਰ ਕੀਤੀ ਮੈਮੋਰੀ ਲਈ ਸਮਕਾਲੀ ਐਕਸੈਸ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਲਿਖਣ ਦੇ ਨਾਲ ਅਤੇ ਕੋਈ ਸਮਕਾਲੀਤਾ ਨਾ ਹੋ), ਇਹ ਪਛਾਣਨਾ ਕਿ ਸਧਾਰਨ-ਦਿਖਣ ਵਾਲਾ ਕੋਡ ਜਿਵੇਂ counter++ ਰੇਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਕਸਸ ਨੂੰ ਜਾਣਨਾ (mutex, atomic, channels) ਸਮਕਾਲੀ Go ਨੂੰ ਠੀਕ ਲਿਖਣ ਲਈ ਜ਼ਰੂਰੀ ਹੈ।
ਆਲੋਚਨਾ ਨਾਲ, Go ਦਾ ਬਿਲਟ-ਇਨ race detector (-race) ਅਪਰਿਹਾਰਜ ਟੂਲ ਹੈ — ਪਰੀਖਿਆਵਾਂ ਨੂੰ ਇਸ ਨਾਲ ਚਲਾਉਣਾ (ਆਦਰਸ਼ ਤੌਰ 'ਤੇ CI ਵਿੱਚ) ਰੇਸਾਂ ਨੂੰ ਫੜਦਾ ਹੈ ਜੋ ਹੋਰ ਅਦ੍ਰਿਸ਼ ਹਨ।
Race detection ਅਤੇ prevention ਵਿੱਚ ਮੁਹਾਰਤ ਪ੍ਰੋਡਕਸ਼ਨ-ਗ੍ਰੇਡ ਸਮਕਾਲੀ Go ਲਈ ਇੱਕ ਬੁਨਿਆਦੀ ਹੁਨਰ ਹੈ ਅਤੇ ਭਾਸ਼ਾ ਵਿੱਚ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਉੱਚ-ਪੱਧਰ ਦੇ ਵਿਸ਼ਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ, ਕਿਉਂਕਿ ਸਮਕਾਲੀਤਾ ਦੀ ਸੁਧਾਰ ਬਿਲਕੁਲ ਉਹੀ ਥਾਂ ਹੈ ਜਿੱਥੇ Go ਪ੍ਰੋਗ੍ਰਾਮ ਸਭ ਤੋਂ ਵੱਧ ਫੇਲ ਹੁੰਦੇ ਹਨ।