Một data race xảy ra khi hai hoặc nhiều goroutine truy cập cùng một vùng bộ nhớ đồng thời, ít nhất một truy cập là ghi, và không có đồng bộ hóa giữa chúng. Kết quả là hành vi không xác định — dữ liệu hỏng, crash, hoặc kết quả sai xuất hiện không liên tục. Go cung cấp một race detector tích hợp sẵn để tìm chúng.
// ❌ DATA RACE — nhiều goroutine ghi cùng một biến mà không đồng bộ hóa
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, nhiều goroutine cùng lúc
}()
}
wg.Wait()
fmt.Println(counter) // thường KHÔNG phải 1000 — các cập nhật bị mất do race
}
counter++ là read-modify-write (ba bước). Khi các goroutine xen kẽ, các cập nhật ghi đè lên nhau, nên số đếm cuối cùng không thể đoán trước. Kết quả thay đổi giữa các lần chạy — bản chất nguy hiểm ngầm của race.
go run -race main.go # chạy với phát hiện race bật
go test -race ./... # chạy test với race detector (thực hành tốt trong CI)
go build -race # build một binary phát hiện race
Race detector báo cáo mỗi race nó quan sát được:
==================
WARNING: DATA RACE
Write at 0x... by goroutine 7: main.main.func1() main.go:12
Previous read at 0x... by goroutine 6: ...
==================
Race detector đo đạc (instrument) các truy cập bộ nhớ tại runtime và báo cáo chính xác nơi một race xảy ra (các truy cập xung đột và goroutine/dòng của chúng). Nó là một trong những công cụ giá trị nhất của Go — chạy test của bạn với -race thường xuyên (đặc biệt trong CI) để bắt race trước production.
// Sửa 1: bảo vệ bằng một mutex
var mu sync.Mutex
mu.Lock(); counter++; mu.Unlock()
// Sửa 2: dùng thao tác atomic (không khóa, cho các giá trị đơn giản)
import "sync/atomic"
var counter int64
atomic.AddInt64(&counter, 1) // atomic — không race
// Sửa 3: đừng chia sẻ — dùng channel để chuyển quyền sở hữu
results := make(chan int)
// mỗi goroutine gửi kết quả của nó; một goroutine tổng hợp
Các cách sửa là các công cụ đồng bộ hóa: một mutex để tuần tự hóa truy cập, các thao tác atomic cho các bộ đếm đơn giản, hoặc channel để tránh chia sẻ bộ nhớ hoàn toàn.
✗ KHÔNG XÁC ĐỊNH — có thể chạy được khi test, thất bại trong production (phụ thuộc thời điểm)
✗ Khó tái tạo — phụ thuộc vào lập lịch goroutine, tải, phần cứng
✗ Hành vi KHÔNG XÁC ĐỊNH — không chỉ giá trị sai; có thể làm hỏng dữ liệu hoặc crash
✗ Thường vô hình nếu không có race detector — không có lỗi, chỉ là kết quả sai một cách tinh vi
Data race nằm trong số các lỗi nguy hiểm nhất và khó debug nhất trong Go concurrent — và thiết kế thiên về concurrency của Go khiến chúng là một rủi ro thực.
Chúng nguy hiểm ngầm vì không xác định: code có race có thể vượt qua mọi test và chạy tốt dưới tải nhẹ, rồi thất bại không liên tục trong production dưới tải concurrent, tạo ra dữ liệu hỏng, kết quả sai, hoặc crash gần như không thể tái tạo.
Hiểu định nghĩa chính xác (truy cập đồng thời vào bộ nhớ chung với ít nhất một ghi và không đồng bộ hóa), nhận ra rằng ngay cả code trông vô hại như counter++ cũng race, và biết các cách sửa (mutex, atomic, channel) là thiết yếu để viết Go concurrent đúng đắn.
Quan trọng nhất, race detector tích hợp sẵn của Go (-race) là công cụ không thể thiếu — chạy test với nó (lý tưởng trong CI) bắt các race vốn vô hình.
Thành thạo phát hiện và phòng ngừa race là một kỹ năng nền tảng cho Go concurrent cấp production và là một trong những chủ đề nâng cao quan trọng nhất của ngôn ngữ, vì tính đúng đắn về concurrency chính là nơi các chương trình Go thường thất bại nhất.