直接读写全局变量在goroutine中会引发数据竞争，因“读-改-写”非原子且map等类型扩容时读写并发会导致panic；Go要求显式同步，如用sync.Mutex、RWMutex、atomic或sync.Map按场景选择。

为什么直接读写全局变量在 goroutine 中会出问题

Go 的 goroutine 是轻量级并发单元，但多个 goroutine 同时读写同一块内存（比如一个 int 或 map）时，不加同步会导致数据竞争（data race）。Go 工具链能检测到这类问题，运行时可能报错：fatal error: concurrent map writes 或触发 go run -race 报告竞争警告。

根本原因不是“Go 不支持并发”，而是 Go 要求你**显式声明临界区**——即哪些操作必须串行执行。这和 C/C++ 依赖程序员自觉加锁不同，Go 把竞争检测做进了工具链，逼你直面问题。

• 常见错误场景：用 map[string]int 做计数器，多个 goroutine 同时执行 counter[key]++
• counter[key]++ 看似原子，实际是“读-改-写”三步，中间可被其他 goroutine 打断
• 即使只读不写，若同时有写操作，也可能读到脏数据或 panic（如 map 扩容中被读）

sync.Mutex 的正确使用姿势

sync.Mutex 是最基础的互斥锁，但它本身不保护任何变量——它只提供“同一时间最多一个 goroutine 能进入某段代码”的能力。关键在于：锁的生命周期、作用域和配对必须严格。

• 锁对象通常作为结构体字段存在，而不是局部变量（否则每次调用都新建一把锁，完全无效）
• Lock() 和 Unlock() 必须成对出现；建议用 defer mu.Unlock() 防止遗漏
• 不要在锁持有期间做耗时操作（如 HTTP 请求、文件 IO），否则阻塞其他 goroutine
• 避免锁嵌套或跨函数传递锁状态，容易死锁

type Counter struct {
    mu sync.Mutex
    v  int
}

func (c *Counter) Inc() {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.v++
}

func (c *Counter) Value() int {
    c.mu.Lock()
    defer c.mu.Unlock()
    return c.v
}

什么时候该用 RWMutex 而不是 Mutex

当读操作远多于写操作，且读操作本身不修改数据时，sync.RWMutex 可显著提升并发吞吐。它允许多个 goroutine 同时读（R Lock），但写操作（Lock）会独占——即“多读单写”模型。

立即学习“go语言免费学习笔记（深入）”；

• 典型适用场景：配置缓存、白名单 map、状态只读快照
• 误用风险：在 R Lock 持有期间调用可能修改数据的函数（哪怕只是间接修改），会导致数据竞争
• 注意：RWMutex 的写锁会阻塞新读锁请求，但已持有的读锁不释放前，写锁会一直等待

type Config struct {
    mu sync.RWMutex
    data map[string]string
}

func (c *Config) Get(key string) string {
    c.mu.RLock()
    defer c.mu.RUnlock()
    return c.data[key]
}

func (c *Config) Set(key, value string) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.data[key] = value
}

比 Mutex 更安全的替代方案：sync/atomic 和 sync.Map

对于简单类型（int32、int64、uint64、指针），sync/atomic 提供无锁原子操作，性能更高且天然线程安全；而 sync.Map 是为“读多写少 + 键值生命周期长”设计的并发安全 map，内部混合使用原子操作与分段锁。

• atomic 不能用于结构体或切片，仅限固定大小整型和指针；atomic.LoadInt64(&x) 比加锁读更快
• sync.Map 不适合高频遍历或需要 range 的场景，它的 Range 方法是快照语义，不保证实时性
• 别为了“看起来高级”强行用 sync.Map 替代普通 map + Mutex——如果写操作频繁，sync.Map 的性能反而更差

真正需要警惕的是：没有银弹。Mutex 明确、可控、易调试；atomic 高效但适用面窄；sync.Map 隐藏了锁细节，出问题时更难定位。选哪个，取决于你的访问模式和可维护性要求。