17370845950

Go中引用类型（如slice、map、channel等）不保证并发安全，多goroutine读写需显式同步；推荐按场景选用sync.RWMutex、sync.Map、sync/atomic或channel。

引用类型本身不保证并发安全

Go 中的切片（slice）、map、channel、指针、函数、接口等属于引用类型，但它们的“引用”特性只表示底层数据结构共享同一块内存，并不意味着操作是原子的或线程安全的。比如多个 goroutine 同时对一个 map 进行读写，会直接触发 panic（fatal error: concurrent map writes）；对切片追加元素（append）也可能因底层数组扩容导致数据竞争。

哪些操作必须加锁

以下情况需要显式同步控制：

• 多个 goroutine 同时写同一个 map（哪怕只是写不同 key）——必须用 sync.RWMutex 或 sync.Map
• 一个 goroutine 写 + 其他 goroutine 读 map —— 仍需锁，因为写操作可能引发扩容，破坏正在读取的迭代状态
• 对非并发安全的结构体字段（如含 slice/map 的 struct）做复合操作（如先查再改）—— 即使字段是引用类型，整体逻辑也需锁保护
• 共享指针指向的数据被多 goroutine 修改（如 *int 被多个 goroutine 增减）—— 基础类型操作虽小，但非原子，需 sync/atomic 或互斥锁

推荐的并发安全方案

优先按场景选合适工具，不盲目上 sync.Mutex：

• 读多写少的 map：用 sync.RWMutex 包裹原生 map，读用 RLock，写用 Lock
• 简单键值缓存：用标准库 sync.Map（适合低频写、高频读，但不支持遍历和 len，且无泛型约束）
• 计数器、标志位等基础操作：用 sync/atomic（如 atomic.AddInt64、atomic.LoadPointer），零分配、无锁、高效
• 天然并发安全的类型：channel 是 Go 原生支持并发通信的机制，用 channel 传递数据比共享内存更符合 Go 的设计哲学（Do not communicate by sharing memory; instead, share memory by communicating.）

避免踩坑的关键习惯

很多数据竞争不是因为不会加锁，而是没意识到要加：

• 不要假设“只读”就绝对安全——如果其他 goroutine 正在写，没锁的读仍是竞态
• 切片的 append 不是原子操作，多 goroutine 并发 append 同一个切片会丢数据或 panic
• 使用 -race 编译参数运行程序（go run -race main.go），它能动态检测大部分数据竞争问题
• 结构体嵌套引用类型时，锁的粒度要覆盖整个业务逻辑，而不是只锁某个字段

基本上就这些。Go 不提供“自动线程安全”的引用类型，安全得靠开发者对共享资源的明确约定和正确同步。用对工具，比拼命加锁更重要。