pprof 能通过 cpu profile 暴露伪共享——关键看 atomic 操作（如 atomic.addint64）占比异常高、火焰图中 lock 指令耗时显著、多 goroutine 操作同缓存行内不同字段时出现高度重叠的延迟。
pprof 本身不能直接识别伪共享，但能帮你定位它——关键看 LOCK 指令耗时和 atomic 操作的异常延迟。
为什么 pprof 的 CPU profile 能暴露伪共享
伪共享不会报错，也不会触发 Go 层面的任何警告，但它会让 atomic.AddInt64、atomic.StoreUint64 等底层指令反复陷入缓存一致性协议开销。x86 上这类操作常编译为 LOCK XADD 或 LOCK CMPXCHG，而这些指令在伪共享严重时会显著拉长执行周期。
pprof 的 CPU profile 正好能捕获这种“本该很快却很慢”的现象：
- 函数调用栈里
atomic.*占比异常高（比如 >30%），且集中在几个 struct 字段上 - 火焰图中对应字段的 atomic 操作节点宽而深，但内部无实际计算逻辑
- 用
go tool pprof -http=:8080 <binary><profile></profile></binary>查看，点开热点函数后执行disasm atomic.AddInt64，能看到大量时间花在LOCK指令等待上
怎么跑出能反映伪共享的 CPU profile
必须让竞争真实发生：多 goroutine 并发写不同字段，且字段物理地址落在同一缓存行。否则 profile 看不到问题。
实操要点：
- 基准测试要足够长（至少 10 秒），避免噪声干扰；用
go test -bench . -cpuprofile cpu.pprof -benchtime=10s - 确保测试运行在多核机器上（
GOMAXPROCS≥ 2），且不被调度器“挤”到单核（可临时设GOMAXPROCS=runtime.NumCPU()） - 避免 GC 干扰：加
debug.SetGCPercent(-1)暂停 GC，或在 profile 前后手动runtime.GC() - 如果用 HTTP pprof，请求要并发打满（如
ab -n 10000 -c 100 http://localhost:6060/debug/pprof/profile?seconds=30），否则单线程压测看不出缓存行争抢
从 pprof 输出里识别伪共享的关键信号
打开 go tool pprof cpu.pprof 后，别只看 top，重点查这几项：
- 执行
top -cum：如果sync/atomic.(*Uint64).Add或类似函数排前三，且其父调用是某个 struct 的方法（如(*Counter).IncA），就要怀疑字段布局 - 执行
list Counter.IncA：确认它是否只做一次atomic.AddUint64(&c.a, 1)—— 若代码极简但耗时高，大概率是缓存行拖慢 - 执行
web看火焰图：若多个 goroutine 的 atomic 调用堆栈高度重叠、底部都卡在 LOCK 指令，且它们操作的是同一 struct 的不同字段（如c.a和c.b），基本坐实伪共享 - 对比内存布局：用
unsafe.Offsetof检查字段偏移，例如unsafe.Offsetof(c.b) - unsafe.Offsetof(c.a)若小于 64 且两者都是int64，就极可能同缓存行
验证填充是否生效的最小闭环
改完 struct 加 [56]byte 填充后，不能只信 benchmark 数字变快了——得用 pprof 确认底层行为已变。
验证步骤：
- 重新跑相同负载的 CPU profile（参数完全一致）
- 进 pprof 执行
top -cum：确认atomic.*占比下降（理想情况降到 5% 以下） - 执行
disasm atomic.AddInt64：LOCK 指令的采样数应大幅减少（不是消失，而是从数千降到百以内） - 用
go tool compile -S main.go | grep "LOCK"对比汇编，确认填充后字段地址跳变（如 a 在 offset 0，b 在 offset 64，而非 8）
真正容易被忽略的是：填充必须覆盖字段两侧，且不能依赖 //go:align 替代；哪怕结构体起始地址对齐了，字段之间依然紧挨着——伪共享只发生在字段级物理位置，不在 struct 实例边界。
