如何使用Golang实现安全的共享数据访问_Golang sync.Mutex与数据保护实践_技术教程

直接读写全局变量在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
}