伪共享是多核CPU中因变量同处一缓存行引发的无效缓存同步现象；缓存行通常64字节，线程写入任一变量即导致整行失效并触发MESI协议开销，需通过perf工具识别并用alignas或padding隔离变量。
伪共享（False Sharing）是多核 CPU 上因缓存行对齐不当导致的性能陷阱：多个线程修改不同变量，却因它们落在同一缓存行而频繁触发缓存同步，白白消耗带宽和时间。
缓存行与伪共享怎么发生的
CPU 缓存不是按字节管理，而是以固定大小的“缓存行”（Cache Line）为单位加载数据，常见大小为 64 字节。当两个变量物理地址落在同一缓存行内，即使被不同线程独占访问，只要任一线程写入，整个缓存行就会被标记为“已修改”。其他核上该行副本随即失效——下次读取必须重新从内存或其它核同步，引发不必要的缓存一致性协议开销（如 MESI 状态切换）。
例如：
- 结构体中两个 bool 成员紧挨着定义：
struct { bool a; bool b; }; - 线程 A 修改
a，线程 B 同时修改b - 若
a和b落在同一 64 字节缓存行，两者会互相“干扰”，性能可能下降数倍
如何识别伪共享
不能靠肉眼判断，需结合工具和模式分析：
- 使用 perf（Linux）观察
cache-misses、mem_load_retired.l1_miss或l2_rqsts.rejected_sw_pfq等事件突增 - 关注高并发下单个核心利用率低但整体吞吐上不去，且变量访问无真正共享逻辑
- 用
__builtin_assume_aligned或调试器检查变量地址，确认是否同属一个 64 字节区间（地址 & ~63 相同）
常用规避方法
核心思路是让高频写入的变量独占缓存行：
-
手动填充（Padding）：在变量前后插入足够字节（如 64 - sizeof(T)），确保它独占一行。C++17 可用
alignas(64)配合 char 数组实现 - 使用 alignas(64) + 独立变量：将热点变量声明为独立全局/静态变量，并强制对齐到缓存行边界
-
避免结构体内混放热字段：把会被不同线程写的字段拆到不同结构体，或用
[[no_unique_address]]（C++20）配合填充控制布局 - 用 std::hardware_destructive_interference_size（C++17）：标准提供的推荐缓存行隔离尺寸（通常为 64），用于 padding 计算更可移植
伪共享不是万能优化点
它只在特定场景显著影响性能：
- 高频率写入（如计数器、标志位）
- 变量被不同物理核上的线程同时修改
- 缓存行竞争成为瓶颈（可通过 perf 确认）
盲目加 padding 会浪费内存、降低 L1 缓存利用率，甚至影响预取效果。应在性能剖析确认问题后再针对性处理。
