Golang值类型在并发场景下的安全性说明

值类型本身非线程安全，“拷贝后使用”可规避竞争，但共享同一内存地址时仍会触发竞态；含指针、map、slice等字段的结构体浅拷贝后仍可能竞争；需依场景选用atomic、mutex或channel。

Golang值类型在并发场景下的安全性说明第1张

值类型本身不是线程安全的，但“拷贝后使用”可规避竞争

Go 中的 int、string、struct 等值类型在被传参或赋值时会复制一份新副本。这意味着：多个 goroutine 同时读写各自持有的副本，不会产生数据竞争——但这不等于“值类型天然并发安全”，关键看是否共享了同一块内存。

常见误解是认为只要用了 int 就不用加锁。错在忽略了变量是否被多个 goroutine 共同指向。比如一个全局 var counter int，被 10 个 goroutine 同时执行 counter++，就会触发竞态（race condition），因为它们操作的是同一个内存地址。

只读场景（如配置参数）：直接传递 int 或 struct 值是安全的
需修改且跨 goroutine 共享状态：必须用同步机制（sync.Mutex、sync/atomic 或 channel）
结构体含指针或 map/slice 字段时：即使类型是值类型，字段仍可能指向共享堆内存，拷贝后仍可能竞争

struct 拷贝陷阱：字段里藏着指针就危险

定义一个看似纯值类型的结构体，但如果它包含 map、slice、*int 或 chan，那它的“值拷贝”只是浅拷贝——底层数据结构仍在共用。这时候并发读写这些字段，依然会出问题。

type Config struct {
    Name string
    Data map[string]int // ⚠️ 这个 map 是引用类型！
    Tags []string         // ⚠️ slice header 被拷贝，底层数组仍共享
}

var cfg Config = Config{Data: make(map[string]int)}
go func() { cfg.Data["a"] = 1 }() // 竞态！
go func() { delete(cfg.Data, "a") }() // 竞态！

检测方式：go run -race main.go 能捕获这类运行时竞态
修复思路：要么用 sync.RWMutex 保护整个结构体访问，要么彻底避免共享——改用 channel 传递更新指令，或每次构造全新结构体 + 不可变字段
注意 time.Time、net.IP 等看似简单但内部含指针的类型，它们的拷贝也是安全的（标准库已确保字段不可变），但自定义结构体不能默认这么假设

何时该用 atomic 而不是 mutex？

对单个 int32、int64、uint32、uintptr、unsafe.Pointer 或布尔值做原子读写时，sync/atomic 比 sync.Mutex 更轻量、无锁且性能更好。但它不适用于复合操作（比如“读-改-写”中的条件判断）。

var counter int64

// ✅ 安全：原子增
atomic.AddInt64(&counter, 1)

// ❌ 危险：非原子的“先读再判断再写”
if counter < 10 {
    counter++ // 竞态！中间可能被其他 goroutine 修改
}

// ✅ 正确：用 CompareAndSwap 实现条件更新
for {
    old := atomic.LoadInt64(&counter)
    if old >= 10 {
        break
    }
    if atomic.CompareAndSwapInt64(&counter, old, old+1) {
        break
    }
}