To effectively handle race conditions in Go, you must first use the built-in race detector and enable the -race flag in tests; 1. Use go run -race or go test -race to detect potential races in development and CI; 2. Protect shared data through sync.Mutex or sync.RWMutex to ensure the atomicity of write operations; 3. Use channels instead of shared memory to share data through communication between goroutines; 4. Use sync/atomic packets for simple operations such as counters to achieve lock-free concurrency security; 5. Avoid goroutine error capture of loop variables, and values should be isolated by passing parameters or local variables. Always run race detection regularly to protect or avoid shared states to effectively prevent race conditions.

Race conditions in Go happen when multiple goroutines access shared data concurrently, and at least one of the accesses is a write. Since Go encourages concurrency through goroutines and channels, it's easy to accidentally introduce race conditions if you're not careful.

Here's how to effectively deal with them:

1. Use the Built-in Race Detector

The Go race detector is your first line of defense. It's not enabled by default, but you should use it during testing.

 go run -race main.go
go test -race mypackage/

The race detector will report potential race conditions at runtime by tracking memory accesses. It adds overhead, so don't use it in production, but always run it during development and CI.

Example output:

 WARNING: DATA RACE
Write at 0x00c00009c020 by goroutine 7
Read at 0x00c00009c020 by goroutine 6

This tool catches real issues and should be part of your testing workflow.

2. Protect Shared Data with sync.Mutex or sync.RWMutex

When goroutines need to read or modify shared variables, use a mutex to synchronize access.

 var (
    counter int
    mu sync.Mutex
)

func increment() {
    mu.Lock()
    defer mu.Unlock()
    counter  
}

Use sync.RWMutex if you have many readers and few writers:

 mu.RLock()
value := sharedData
mu.RUnlock()

// For writes:
mu.Lock()
sharedData = newValue
mu.Unlock()

Tip : Keep critical sections (code between Lock/Unlock) as small as possible to avoid blocking unnecessarily.

3. Use Channels instead of Shared Memory

Go's philosophy is: "Do not communicate by sharing memory; share memory by communicating."

Instead of protecting shared state with mutexes, use channels to pass data between goroutines.

 func worker(in <-chan int, out chan<- int) {
    for n := range in {
        out <- n * n
    }
}

// Usage:
jobs := make(chan int, 100)
results := make(chan int, 100)

go worker(jobs, results)
jobs <- 5
close(jobs)

result := <-results

This avoids shared state entirely — each goroutine owns its data, and communication happens safely over channels.

4. Use sync/atomic for Simple Operations

For low-level operations on numeric types (eg, counters), sync/atomic provides lock-free, thread-safe primitives.

 import "sync/atomic"

var counter int64

func increment() {
    atomic.AddInt64(&counter, 1)
}

func getCounter() int64 {
    return atomic.LoadInt64(&counter)
}

This is faster than mutexes for simple operations but only works for specific types and operations (add, compare-and-swap, load/store, etc.).

Use atomic when you're doing simple reads/writes and want minimum overhead.

5. Avoid Closures Capturing Loop Variables

A common source of race conditions is goroutines capturing loop variables incorrectly:

 // ? Dangerous!
for i := 0; i < 10; i {
    go func() {
        fmt.Println(i) // All goroutines may print 10
    }()
}

Fix it by passing the value as an argument:

 // ? Safe
for i := 0; i < 10; i {
    go func(val int) {
        fmt.Println(val)
    }(i)
}

Or create a local copy inside the loop.

Summary of Best Practices

• ? Always run go test -race regularly.
• ? Use sync.Mutex or sync.RWMutex to protect shared mutable state.
• ? Prefer channels over shared memory when possible.
• ? Use sync/atomic for simple atomic operations.
• ? Be careful with loop variables captured in goroutines.

Race conditions are subtle and hard to reproduce, but with the right tools and patterns, they're entirely manageable in Go.

Basically: detect early, protect shared state, or better yet, avoid sharing it.

The above is the detailed content of How to deal with race conditions in Golang?. For more information, please follow other related articles on the PHP Chinese website!