Go 原子指针和互斥锁怎么按读写模式选择

Go 里选原子指针还是互斥锁，先看“要保护的是一个指针，还是一组必须同时成立的状态”。如果共享内容可以先构造成不可变的 Config，再整体替换指针，优先考虑 atomic.Pointer[Config]；如果一次操作要同时读写余额、版本号或多个字段，就让 sync.Mutex 包住整个不变量。读多写少并不会自动让原子操作更正确，正确的访问配对比单纯追求少一把锁更重要。

先按共享状态的形状做选择

原子指针解决的是“这个指针当前指向哪个完整对象”。它不会替你保护对象内部字段。如果配置对象创建完成后不再修改，更新方可以准备一份新对象，再一次性发布新指针；读方通过原子 Load 拿到一个稳定快照。

Mutex 的边界更大：它把进入临界区的 goroutine 排他化，适合需要“读取旧值、计算新值、校验多个字段、一起提交”的操作。下面这张图把两种模式的角色和关系放在同一组静态边界里，便于先判断状态形状。

用 atomic.Pointer[T] 表达单一指针状态

Go 1.19 引入的泛型 atomic.Pointer[T] 比裸 unsafe.Pointer 更容易保持类型一致。下面的写法把 Config 视为发布后不可变对象：读协程只加载，更新协程构造新值后存入。代码中的 CompareAndSwap 则适合“只有当前版本仍是旧指针时才替换”的条件更新。

type Config struct {
	Endpoint string
	Timeout  time.Duration
}

var current atomic.Pointer[Config]

func ReadConfig() *Config {
	// 原子读取当前完整配置；返回对象发布后不再原地修改。
	return current.Load()
}

func PublishConfig(endpoint string, timeout time.Duration) {
	// 先构造完整对象，再一次性发布，避免读方看到半成品。
	current.Store(&Config{Endpoint: endpoint, Timeout: timeout})
}

func ReplaceIfSame(old, next *Config) bool {
	// 只有指针仍指向 old 时才替换，失败表示期间已有更新。
	return current.CompareAndSwap(old, next)
}

这个模式的关键不是“没有锁”，而是把共享状态收窄为一个原子指针，并且禁止发布后修改 Config 的字段。若拿到指针后继续原地改 Timeout，读方仍可能与写方产生数据竞争；此时应改成复制后整体发布，或退回互斥锁。

用 Mutex 保护多个字段的不变量

假设一个账户状态要求余额和版本号一起变化：余额增加时版本号必须递增，读取结果也必须来自同一个版本。把两个字段分别做原子读写仍然可能读到“余额是新值、版本号是旧值”的组合。这里需要的是复合一致性，而不是两个独立的原子变量。

type Store struct {
	mu      sync.Mutex
	balance int64
	version uint64
}

func (s *Store) Snapshot() (int64, uint64) {
	s.mu.Lock()
	defer s.mu.Unlock() // 保证所有返回路径都会释放锁。
	return s.balance, s.version
}

func (s *Store) Add(delta int64) {
	s.mu.Lock()
	defer s.mu.Unlock()
	// 两个字段和校验规则属于一次提交，不能拆成两把“逻辑锁”。
	s.balance += delta
	s.version++
}

Mutex 的零值即可使用，但首次使用后不能复制。方法接收者通常使用指针，结构体也不要通过值传递。锁的范围应覆盖完整不变量，同时尽量不要把网络请求、磁盘读写等不可控耗时操作放进临界区。

检查对齐、复制和混用风险

原子访问必须使用同一套访问方式。对某个地址调用 atomic.Load，并不能允许另一处用普通赋值写回；只要存在一条未同步的普通读写，数据竞争仍然成立。运行 go test -race ./... 能帮助发现不少混用路径，但它不能代替对共享状态边界的设计。

如果使用旧式的 atomic.LoadInt64 或 StoreInt64，在 32 位 ARM、386 和 32 位 MIPS 上要特别留意 64 位值的对齐。把它放在结构体首个字段、全局变量或独立分配的对象中更稳妥；使用 atomic.Int64、atomic.Uint64 等类型时，标准库会自动处理类型自身的对齐要求。无论原子类型还是 Mutex，都不要在并发使用后复制。

用读写模式落地选择清单

可以按下面的顺序做决定：第一，问共享对象能否构造完成后保持不可变；能，就把“替换整个指针”作为原子方案。第二，问一次业务操作是否需要同时观察和更新两个以上字段；需要，就用一把锁包住整个操作。第三，确认所有访问点是否都使用同一种同步协议，尤其检查辅助函数和缓存路径。最后再看性能：只有在锁竞争已经被测量、且状态确实是单一可替换值时，才值得把实现收窄到原子指针。

一句实用的经验是：原子指针让“对象发布”变简单，互斥锁让“状态变更”更完整。前者的代价是对象必须遵守不可变约束，后者的代价是临界区可能产生等待。先画清楚共享状态边界，再谈读多写少，通常更不容易选错。

相关问题

atomic.Pointer[T] 能直接保护指向对象的字段吗？

不能。它只原子地保护指针本身；对象发布后应视为不可变，字段需要原地修改时应使用锁或重新构造对象后整体替换。

读多写少就一定应该不用 Mutex 吗？

不一定。读写比例只能说明竞争可能性，不能说明状态是否具备单一指针形状。多个字段要保持一致时，Mutex 通常更直接。

atomic.Pointer 和 unsafe.Pointer 怎么选？

新代码优先使用带类型参数的 atomic.Pointer[T]。只有编写非常底层的兼容代码时才考虑 unsafe.Pointer，并把类型转换和生命周期约束集中在很小的范围内。