False Sharing 是指逻辑无关变量因位于同一 CPU 缓存行而引发无效同步；Go 中因 runtime 不暴露缓存行对齐、编译器不自动填充，且默认按类型自然对齐，导致跨字段 False Sharing 难以察觉。
False Sharing 是什么，为什么 Go 程序里它特别隐蔽
Go 的 runtime 不暴露 CPU 缓存行（cache line）对齐细节，但 struct 字段若跨缓存行分布、又被不同 goroutine 高频写入相邻字段，就会触发 False Sharing——两个逻辑无关的变量，因物理上挤在同一 cache line 里，导致 CPU 核心反复无效同步整条 line。现象是：加了 sync.Mutex 或 atomic 操作后性能不升反降，pprof 显示大量 runtime.usleep 或 runtime.futex 调用。
根本原因在于 Go 编译器默认按字段类型大小自然对齐，不主动填充；而 x86-64 缓存行通常是 64 字节，只要两个被并发写的字段落在同一 64 字节区间内，就危险。
怎么确认结构体字段真正在“抢”同一 cache line
不能靠猜，得用工具定位。最直接的是用 go tool compile -S 看字段偏移，再人工算是否落入同一 64 字节块；更稳妥的是跑 go test -bench . -cpuprofile=prof.out，然后 go tool pprof prof.out 进入交互模式，执行 top -cum 查看热点函数中 struct 字段访问的汇编偏移。
- 关键指标：看
MOVQ/ADDQ指令操作的地址是否都在同一 64 字节范围内（比如偏移 16 和 24，或 56 和 60） - 注意
unsafe.Offsetof返回的是字节偏移，可直接用于判断：offset1/64 == offset2/64就说明在同一 cache line - 别依赖
reflect.TypeOf(t).Size()，它只返回总大小，不反映对齐间隙
填充字段必须手动加，且位置很关键
Go 没有 alignas 或 __attribute__((aligned))，唯一可靠方式是插入占位字段，比如 _ [7]uint64 补满到下一个 cache line 起点。但填充位置不对，等于白干。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 填充必须放在「被高并发写」的字段之后、下一个「也被高并发写」的字段之前
- 错误示范：
type S struct { A int64; _ [7]uint64; B int64 }—— 如果只有A被 goroutine A 写、B被 goroutine B 写，这样是对的；但如果A和C（第三个字段）才是一对竞争者，中间填了却漏掉A和C之间，就无效 - 推荐策略：把每个「独占写」字段单独包进子 struct，用 padding 包裹，例如
type paddedInt64 struct { v int64; _ [56]byte }（64 - 8 = 56），再在主 struct 中使用paddedInt64 - 别用
[0]byte或空 struct 做 padding，它们不占空间，编译器会忽略
填充不是万能的，小心副作用
填充让 struct 更大，可能引发 GC 压力上升、内存带宽占用增加，尤其当 struct 大量分配（如 channel 缓冲区元素、map value）时。
- 如果 struct 主要用于读多写少场景，False Sharing 影响极小，强行填充反而降低缓存局部性
- 填充后
unsafe.Sizeof变大，若该 struct 用作 cgo 参数或网络序列化，需同步调整 C 端或协议定义 - Go 1.21+ 对 small struct 的栈分配更激进，过大的 padding 可能让原本栈分配的 struct 被迫逃逸到堆，用
go build -gcflags="-m"确认 - 填充无法解决指针字段指向的共享内存问题（比如多个 goroutine 写
*int64指向同一地址），那得靠设计隔离
False Sharing 的优化永远得从真实 profile 出发，不是 struct 一长就填，也不是字段一多就 pad。最常被忽略的是：你以为在优化字段 A 和 B，结果 pprof 显示热点其实在字段 C 和 D 的 false 共享上——所以先看数据，再动手。
