伪共享是多个CPU核心因访问同一缓存行中不同变量而触发频繁缓存失效，导致性能下降；在C++中常暴露于未对齐的atomic变量共处一缓存行时，需用alignas(64)加填充确保单变量独占缓存行。
什么是伪共享，它在 C++ 多线程中如何暴露？
伪共享发生在多个 CPU 核心频繁读写**同一缓存行（cache line）中的不同变量**时。即使这些变量逻辑上互不相关、各自被不同线程独占访问，只要它们落在同一个 64 字节（典型 x86-64 缓存行大小）的内存区域里，就会因缓存一致性协议（如 MESI）反复使缓存行失效而严重拖慢性能。
典型暴露场景：std::vector<:atomic>></:atomic> 存储多个计数器，每个线程只改自己的索引，但相邻 atomic<int></int> 变量未对齐或未填充，导致它们挤在同一缓存行；或者自定义结构体中两个 std::atomic<bool></bool> 成员紧挨着，被不同线程轮询/修改。
用 alignas + 填充确保单变量独占缓存行
最直接可靠的方式是强制每个热点原子变量独占一个缓存行。现代 C++ 提供 alignas 控制对齐，配合手动填充（或使用标准库辅助）即可实现。
-
alignas(64)要求变量起始地址是 64 的倍数，但仅对齐不等于隔离——还需保证变量本身不“溢出”到下一行 -
std::atomic<int>通常仅占 4 字节，所以必须补足至 ≥64 字节才能避免相邻变量侵入 - 推荐封装成带填充的模板结构体，而非裸用
alignas变量（后者易被误用或优化干扰）
struct alignas(64) cache_line_padded_int {
std::atomic<int> value{0};
char _pad[64 - sizeof(std::atomic<int>)]; // 精确填充至 64 字节
};这样每个 cache_line_padded_int 实例都独占一整行，无论数组怎么排布都不会伪共享。
立即学习“C++免费学习笔记（深入）”；
慎用 std::hardware_destructive_interference_size
C++17 引入了 std::hardware_destructive_interference_size，理论上应返回缓存行大小。但它在多数编译器（GCC/Clang/MSVC）当前版本中仍被定义为 64，且不保证运行时真实值，也不能用于 alignas（因其非字面常量）。
- 不能写
alignas(std::hardware_destructive_interference_size)—— 编译失败 - 可用作注释或断言依据，例如：
static_assert(sizeof(cache_line_padded_int) >= std::hardware_destructive_interference_size); - 实际部署时仍建议硬编码
64或根据目标平台明确指定（如 ARM64 某些芯片用 128 字节）
其他常见踩坑点和替代方案
伪共享不是只靠 padding 就能一劳永逸的问题。以下情况容易忽略：
- 动态分配的数组（如
new cache_line_padded_int[N]）：即使单个元素对齐，整个数组仍可能跨缓存行紧密排列，需确认分配器是否满足对齐要求（推荐用aligned_alloc或std::pmr::polymorphic_allocator） - 结构体嵌套：若外层结构体含多个缓存行敏感成员，需逐个 padding，不能只对齐整个结构体
- 过度 padding 浪费内存带宽：尤其在大量小对象场景（如每线程 1000 个计数器），总内存翻倍会加剧 TLB 压力
- 替代思路：用线程局部存储（
thread_local）暂存中间结果，周期性合并到全局变量——这从源头避开多核争抢，比 padding 更省空间
真正影响性能的从来不是“有没有 padding”，而是你是否验证过缓存行争用确实存在。先用 perf stat -e cache-misses,cache-references 或 VTune 观察 L1D 缓存失效率，再动手改内存布局。
