缓存行填充在高并发计数器中特别关键，是因为当 hits 和 misses 两个 int64 字段落在同一 64 字节缓存行时，多核高频原子写会触发伪共享，导致 cpu 频繁同步整行缓存、cache miss 激增、qps 下降；手动填充需在字段前后各加 [56]byte 确保独占缓存行，且必须用 release 构建+perf/pgof 验证实效。
为什么缓存行填充在高并发计数器里特别关键
当多个 goroutine 频繁调用 atomic.AddInt64 更新同一结构体里的不同 int64 字段（比如 hits 和 misses），而这两个字段又落在同一 CPU 缓存行（x86-64/ARM64 通常是 64 字节）时，就会触发伪共享。现象是：CPU 使用率飙升、QPS 上不去、pprof 显示大量时间卡在 runtime.futex 或 LOCK XADD 指令上——不是代码写得慢，是硬件在反复同步整行缓存。
怎么手动加 padding 让字段独占缓存行
不能靠 //go:align 64，它只对结构体起始地址对齐有效，不改变字段间偏移；也不能只在字段后面加 [56]byte，因为前一个字段可能已经挤进同一行。必须让目标字段前后都有足够空间。
- 硬编码 64 字节最稳妥（主流平台一致），别依赖
runtime/internal/sys.CacheLineSize - 用
[56]byte填充比多个int64更可靠：编译器不会优化掉未命名数组，且能精确控制偏移 - 填充字段名建议带
pad后缀（如pad0），避免被误认为业务字段 - 导出字段（首字母大写）才能保证
unsafe.Offsetof行为可预测
正确示例：
type Counter struct {
pad0 [56]byte
hits int64
pad1 [56]byte
misses int64
pad2 [56]byte
}
哪些场景真需要填，哪些纯属过度优化
伪共享只有在「多核高频写不同字段 + 字段同缓存行」同时成立时才显著拖慢性能。不是所有并发结构都要处理。
- 要填：goroutine 池中每个 worker 持有独立
Counter，且每微秒级调用一次atomic.AddInt64 - 要填：ring buffer 的
head和tail（都是int64），由不同线程读写 - 不用填：配置结构体里几个
bool字段，只在启动时初始化一次 - 不用填：被
sync.Mutex保护的字段——锁本身已串行化，伪共享影响被掩盖
验证填充是否真的起效
别信感觉。用真实指标说话：
- 用
unsafe.Offsetof打印字段偏移，确认hits和misses地址差 ≥ 64 - 压测对比 P99 延迟和 QPS，尤其看高并发下延迟是否收敛
- 用
perf stat -e cache-misses,cache-references看缓存未命中率是否下降 - 测试务必用 release 构建（
go build默认），禁用优化（-gcflags="-N -l"）会让 padding 失效
真正难的不是加那几行 [56]byte，而是判断哪个字段组合在哪个压测流量下开始成为瓶颈——这没法靠静态分析，得靠 perf 和 pprof 抓现场。
