Go中不存在独立的“内存可见性”概念，其并发问题本质是data race；应使用sync.Mutex或sync.RWMutex保护共享变量，或通过channel通信传递副本，避免共享内存；sync/atomic仅适用于基础类型原子操作，且无法保证多变量协同状态一致性。
Go 中没有“内存可见性”这个独立概念
Go 语言规范不定义类似 Java 的 happens-before 模型，也不提供 volatile 关键字。所谓“并发内存可见性问题”，在 Go 中本质是 data race —— 即多个 goroutine 同时读写同一变量且无同步约束。Go 的 go run -race 工具能检测它，但不会帮你“修复可见性”，只会报错。
用 sync.Mutex 或 sync.RWMutex 保护共享变量
这是最直接、最不容易出错的方案。只要所有读写都经由同一把锁保护，就天然满足顺序一致性语义，不存在“写完读不到”的情况。
- 不要只在写操作加锁、读操作裸奔 —— 这仍是 data race
- 避免锁粒度过大（如整个函数体加锁），但更不能为了性能漏锁关键字段
-
sync.RWMutex在读多写少场景下可提升吞吐，但注意RUnlock()必须配对，否则会死锁
var mu sync.RWMutex
var counter int
func Inc() {
mu.Lock()
counter++
mu.Unlock()
}
func Get() int {
mu.RLock()
defer mu.RUnlock()
return counter
}
channel 是首选的通信方式，不是共享内存的替代品
Go 的哲学是 “Don’t communicate by sharing memory; share memory by communicating”。用 channel 传递值，本质上是复制而非共享，天然规避可见性与竞争问题。
- 向 channel 发送一个
int，接收方拿到的是副本，和发送方的原始变量无关 - 不要用 channel 传递指针并期望在接收端修改原变量 —— 这又回到了共享内存的老路
- 无缓冲 channel 的 send/receive 操作本身构成同步点，隐含 happens-before 关系
sync/atomic 仅适用于基础类型且需严格对齐
sync/atomic 提供原子读写，但仅支持 int32、int64、uint32、uint64、uintptr、unsafe.Pointer 和若干指针类型。它不保证其他字段的可见性，也不能用于 struct 字段级原子操作。
立即学习“go语言免费学习笔记（深入）”；
- 32 位系统上
int64原子操作要求 8 字节对齐，否则 panic（panic: runtime error: invalid memory address or nil pointer dereference） - 不要混用
atomic.StoreInt64()和普通赋值 —— 后者不提供原子性也不触发内存屏障 -
atomic.LoadUint64()读到的一定是某次atomic.StoreUint64()写入的完整值，但不保证“最新”—— 它只是原子，不是自动刷新缓存
真正容易被忽略的是：即使用了 atomic，若逻辑上依赖多个变量的协同状态（比如 status + data），单靠 atomic 无法保证它们的组合状态一致 —— 这时候必须回到 mutex 或重新设计数据流。
