竞态条件是多个goroutine无同步地读写共享内存导致行为不可预测；应通过Mutex、RWMutex或atomic避免。Mutex需保护所有访问并合理控制粒度；RWMutex适用于读多写少场景；atomic适合简单数值和指针的无锁操作。
理解竞态条件的本质
当多个 goroutine 同时读写同一块内存（比如一个全局变量或结构体字段），且没有同步机制时，程序行为变得不可预测——这就是竞态。Go 的 race detector 可以在运行时帮你发现它：go run -race main.go。但检测只是辅助，真正解决问题要靠设计：要么避免共享，要么控制访问。
用 sync.Mutex 保护临界区
Mutex 是最常用、最直观的互斥手段。它不关心你读还是写，只要进入临界区前加锁、离开后解锁即可。注意：锁必须保护所有对共享数据的访问，包括读操作，否则仍可能读到中间状态。
- 定义共享变量时，把 mutex 和数据封装进结构体，避免裸露全局变量
- 使用 defer mu.Unlock() 确保即使 panic 也能释放锁
- 避免锁粒度过大（比如整个函数都锁住），也避免过小（频繁加锁开销高）；按逻辑边界划分临界区
用 sync.RWMutex 区分读写场景
如果读多写少（如配置缓存、状态快照），RWMutex 比普通 Mutex 更高效：多个 goroutine 可同时读，但写时会独占。注意：写锁会阻塞新读锁，读锁也会阻塞新写锁，所以不能在持有读锁时尝试升级为写锁（会死锁）。
- 读操作用 RLock()/RUnlock()，写操作用 Lock()/Unlock()
- 适合“初始化后只读、偶尔更新”的模式，比如服务启动时加载配置，运行中只读取、极少数情况热更新
用原子操作处理简单数值和指针
对于 int32/int64/uint32/uint64/uintptr/unsafe.Pointer 这类固定大小类型，sync/atomic 提供无锁的原子读写和 CAS（CompareAndSwap）。它比 mutex 轻量，但仅适用于单个值，且不能组合多个操作（比如“先读再加再写”不是原子的，得用 CAS 循环实现）。
立即学习“go语言免费学习笔记（深入）”；
- 计数器、开关标志、指针替换（如原子更新配置指针）是典型适用场景
- 注意：atomic.LoadInt64 必须与 atomic.StoreInt64 配对使用同一变量，不能混用普通赋值
- Go 1.19+ 支持泛型原子值 atomic.Value，可安全存取任意类型（底层用反射+互斥，非纯硬件原子，但接口更友好）
