伪共享是CPU缓存行机制导致的性能问题：多个goroutine高频修改同一缓存行内不同变量，引发频繁缓存同步，使sync/atomic操作变慢；需用[56]byte填充确保字段独占64字节缓存行。
什么是伪共享，为什么它会让 sync/atomic 操作变慢
伪共享不是 Go 独有，而是 CPU 缓存行（cache line）机制引发的性能陷阱：当多个 goroutine 频繁读写不同变量，但这些变量恰好落在同一缓存行（通常是 64 字节），CPU 就会反复在核心间同步整行数据，哪怕它们改的是完全无关的字段。
典型表现是：sync/atomic.AddInt64 或 atomic.StoreUint64 在高并发下耗时陡增，pprof 显示大量时间花在 LOCK XADD 或缓存一致性协议开销上，而非真正计算。
Go 的 struct 内存布局默认紧凑，int64 字段挨着放，极易触发伪共享——尤其在计数器、状态标志等高频更新场景中。
如何用 padding 手动对齐到缓存行边界
最直接的办法是让敏感字段独占一个缓存行。x86-64 和 ARM64 主流平台缓存行宽度为 64 字节，所以需确保目标字段前后至少留出 56 字节（假设字段本身 8 字节）的填充空间。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
[56]byte填充比用int64更可靠：后者可能被编译器重排或优化掉，而未命名的数组字段不会参与计算，且能强制内存偏移 - 填充必须放在字段「两侧」：只填后面不够，因为前一个字段可能也属于同一缓存行
- 不要依赖
unsafe.Alignof判断是否对齐；它返回的是对齐要求（如 8），不是缓存行大小
示例：
type Counter struct {
pad1 [56]byte
val int64
pad2 [56]byte
}
这样 val 一定独占一个缓存行，atomic.StoreInt64(&c.val, x) 不再干扰邻近字段。
go:align 指令不能解决伪共享
Go 1.21 引入的 //go:align 是编译器提示，仅影响 struct 实例在内存中的起始地址对齐，不控制字段内部偏移。即使你写 //go:align 64，struct{ a, b int64 } 的两个字段仍紧挨着，共用一行缓存。
-
//go:align对单字段 struct 有效，但对多字段、需隔离的场景无用 - 它不改变字段顺序，也不插入 padding；编译器仍按最小内存占用策略布局
- 实测中，加了
//go:align 64却没加 padding 的计数器，性能和没加一样
哪些场景必须手动 padding，哪些可以不管
伪共享只有在「多核同时写不同变量 + 变量同缓存行 + 高频更新」三者叠加时才显著拖慢性能。不是所有并发结构都需要处理。
- 需要 padding：goroutine 池里的每个 worker 持有独立
Counter，且每毫秒调用一次atomic.AddInt64 - 不需要 padding：配置结构体里几个
bool字段，只在启动时初始化一次；或map的 value 是 struct，但 key 分布均匀、并发写不同 key - 注意 false positive：用
go tool trace看到runtime.usleep或调度延迟高，不等于伪共享；先确认pprof -http中sync/atomic调用本身耗时异常
真实项目里，90% 的 struct 不用动；但一旦动，就得动全——漏掉任一侧 padding，就白做了。
