什么是伪共享，为什么 Go 程序会中招
伪共享不是 Go 特有，但 Go 的 sync/atomic 和高密度结构体字段访问让它更容易暴露。当两个不同 goroutine 频繁写入同一 CPU 缓存行（通常是 64 字节）里的不同变量时，即使逻辑上互不干扰，也会因缓存一致性协议反复无效化整行，导致性能陡降——现象是：CPU 使用率高、实际吞吐却上不去，pprof 显示大量时间花在 runtime.futex 或 runtime.usleep 上。
Go 编译器不会自动插入填充字段，结构体字段按声明顺序紧挨着排布，int64 和 uint64 对齐要求是 8 字节，但若两个 int64 中间没隔开，很可能落在同一缓存行里。
用 cache.LineSize 和填充字段手动对齐
Go 标准库没有内置缓存行大小常量，但 runtime/internal/sys 里有 CacheLineSize；生产代码别直接 import 内部包，稳妥做法是硬编码 64（x86-64 / ARM64 主流都是 64 字节），或用 go:build 条件编译区分。
- 填充字段必须是导出的（首字母大写），否则
unsafe.Offsetof可能失效，且要确保类型大小可预测：优先用[64]byte或[7]uint64（56 字节）+uint64（补到 64） - 填充字段名建议带
pad后缀，比如pad0、pad1，避免被误读为业务字段 - 别把填充加在结构体末尾——末尾填充不影响字段对齐，只影响结构体整体大小；关键是要让「热点写字段」彼此间隔 ≥64 字节
示例：
立即学习“go语言免费学习笔记（深入）”；
type Counter struct {
hits int64
pad0 [56]byte // 8 + 56 = 64 → hits 占满第 1 行
misses int64
pad1 [56]byte // misses 单独占第 2 行
}
哪些场景必须检查伪共享
不是所有并发计数都需要对齐。只有当多个 goroutine 持续、高频（比如每微秒级）更新不同字段，且这些字段又恰好属于同一结构体时，才值得干预。
- 高性能 metrics 收集器（如自研 Prometheus client 中的
CounterVec底层） - Ring buffer 的 head/tail 指针（
int64类型，常被不同线程读写） - 无锁队列节点里的状态字段与 next 指针
- 注意：
sync.Mutex保护的字段不用对齐——锁本身已造成串行，伪共享影响被掩盖
验证是否真的起效
别靠猜。用 perf stat -e cache-misses,cache-references 对比优化前后，看缓存未命中率是否下降；更直接的是压测 QPS/延迟，尤其关注 P99 延迟是否收敛。
- 用
unsafe.Offsetof打印字段偏移，确认两个字段差值 ≥64 - 禁用编译器优化（
go build -gcflags="-N -l"）可能让填充失效，测试务必用 release 构建 - ARM64 有些芯片缓存行是 128 字节，如果目标部署环境混杂，保守起见用
[128]byte填充
真正难的是定位——它不报错，也不 panic，只悄悄拖慢你的服务。一旦怀疑，先用 perf record -e cycles,instructions,cache-misses 录一段，再 perf report 看热点函数里有没有异常高的 cache-misses 比例。
