qps卡住不是代码慢，而是伪共享导致cpu反复同步同一缓存行；需用[56]byte前后填充导出字段（如pad0、hits、pad1、misses、pad2），确保地址差≥64字节，并通过unsafe.offsetof、压测及perf验证。
为什么 atomic.AddInt64 频繁调用后 QPS 卡住不动
不是代码逻辑慢，是 CPU 在反复同步同一缓存行。当 hits 和 misses 两个 int64 字段落在同一 64 字节缓存行（x86-64/ARM64 默认），而多个 goroutine 每微秒级调用 atomic.AddInt64 更新它们时，就触发伪共享：一个核改 hits，另一个核的缓存行立刻失效；它再改 misses，又把前一个核的行踢掉——循环往复，runtime.futex 和 LOCK XADD 占满 CPU 时间。
怎么加 padding 才真正让字段独占缓存行
不能只在字段后加 [56]byte，也不能依赖 //go:align 64 —— 它只对结构体起始地址生效，不控制字段偏移。必须确保目标字段前后都有足够空间，硬编码 [56]byte 最稳妥（64 − 8 = 56）。
-
pad0、pad1这类字段名要带pad后缀，避免被误认为业务字段 - 所有字段必须导出（首字母大写），否则
unsafe.Offsetof行为不可预测 - 填充数组用
[56]byte，不用多个int64：编译器不会优化掉未命名数组，且能精确控制字节偏移
正确写法：
type Counter struct {
pad0 [56]byte
Hits int64
pad1 [56]byte
Misses int64
pad2 [56]byte
}
哪些场景真该填，哪些纯属白忙活
伪共享只在「多核高频写不同字段 + 字段同缓存行」同时成立时才显著拖慢性能。填错地方反而增加内存占用、降低 L1 缓存利用率。
- 要填：
ring buffer的head和tail（都是int64），由不同 goroutine 独立读写 - 要填：goroutine 池中每个 worker 持有独立
Counter，且每几微秒就调一次atomic.AddInt64 - 不用填：配置结构体里几个
bool字段，只在启动时初始化一次 - 不用填：被
sync.Mutex保护的字段——锁已串行化，伪共享影响被掩盖
怎么验证 padding 到底有没有起效
别信感觉，得看真实指标。手动加了 [56]byte 不等于问题消失。
- 用
unsafe.Offsetof打印字段偏移，确认Hits和Misses地址差 ≥ 64 - 压测对比 P99 延迟和 QPS，尤其观察高并发下延迟是否收敛、QPS 是否明显提升
- 用
perf stat -e cache-misses,cache-references看缓存未命中率是否下降 - 测试务必用 release 构建（
go build默认），禁用优化（-gcflags="-N -l"）会让 padding 失效
真正难的不是写那几行 [56]byte，而是判断哪两个字段组合正在互相污染缓存行——这需要结合 pprof、perf 和实际访问模式交叉验证。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
