并发读单写场景下需为变量加互斥锁吗？RWMutex与atomic.Bool差异解析

示例代码 #

func NewExample() *Example {
    return &Example{}
}

type Example struct {
    foo bool
}

func (e *Example) Start(ctx context.Context) {
    go func() {
        ticker := timer.NewTicker(time.Second)
        // this goroutine listens for ticker and might change the foo value of the struct
    }()
}

func (e *Example) GetFoo() bool {
    return e.foo
}

问题1：当多个goroutine对Example.foo执行读取操作，仅单个goroutine进行写入操作时，是否需要为Example.foo加互斥锁？请说明原因。 #

需要加同步保护（比如互斥锁），核心原因有两点：

1. 内存可见性：Go的内存模型不保证单个写goroutine修改的值能被并发的读goroutine及时看到——CPU缓存、指令重排等底层机制会导致读操作读取到旧的缓存值，哪怕只有一个写goroutine，只要有多个读goroutine在并发访问，就必须通过同步手段确保写操作的结果对读goroutine可见。
2. 竞态条件：只要写操作和读操作是并发执行的，就属于Go定义的竞态场景（至少一个goroutine写，同时有其他goroutine读/写同一变量），这种情况会触发竞态检测工具的告警，且可能导致不可预期的程序行为。

问题2：使用RWMutex访问/修改Example.foo，与将Example.foo声明为atomic.Bool类型，二者有什么区别？ #

这两种方案的核心区别体现在适用场景、性能开销和灵活性上：

• 粒度与适用场景：
  sync.RWMutex是用来保护一块代码或一组关联变量的同步原语，适合当你需要对foo的读写结合其他逻辑，或者后续要给结构体添加更多需要同步的字段时使用。它支持多读单写的并发模式，在读多写少的场景下效率表现不错。
  atomic.Bool是专门针对单个布尔值的原子操作组件，只能处理该值的加载（Load）和存储（Store），粒度极细，仅适合仅需对单个布尔值做原子读写的简单场景。
• 性能开销：
  atomic操作是硬件指令级别的同步，开销极小，几乎等同于直接内存操作；而RWMutex是操作系统级别的锁，即便Go做了优化，其开销也远大于原子操作，尤其是在锁竞争频繁时，性能差距会更明显。
• 使用复杂度：
  atomic.Bool用法简单，直接调用Load()和Store()方法即可，无需手动加解锁，出错概率低；RWMutex需要手动管理读锁（RLock()/RUnlock()）和写锁（Lock()/Unlock()），一旦忘记解锁就会导致死锁，使用时需要更谨慎。
• 扩展性：
  如果之后需要给Example结构体添加其他字段，且这些字段和foo需要一起进行同步读写，RWMutex可以直接扩展保护整个结构体；而atomic.Bool只能管控自身，其他字段需要额外添加同步措施。

内容的提问来源于stack exchange，提问作者Yuri Tinyukov