伪共享是缓存行粒度与线程写行为不匹配导致的性能陷阱，解决核心是控制变量物理内存布局；仅结构体整体alignas(64)不足，须对每个需隔离变量用alignas(std::hardware_destructive_interference_size)或封装独立对齐结构。
伪共享不是代码逻辑错误，而是缓存行粒度与线程写行为不匹配引发的性能陷阱；它在多线程高频写场景下常导致吞吐量不升反降，甚至下降60%以上。解决它的核心不是加锁或改算法，而是控制变量的物理内存布局。
alignas(64) 对齐结构体成员是否足够？
不够。仅对结构体整体使用 alignas(64) 只保证该结构体起始地址对齐，不保证内部多个成员彼此隔离。例如：
struct BadCounter {
alignas(64) std::atomic<int64_t> a;
alignas(64) std::atomic<int64_t> b;
};
这段代码中 a 和 b 仍可能被编译器紧凑排布（尤其在非POD类型或优化开启时），实际只占16字节，落在同一缓存行内。
- 正确做法是让每个需隔离的变量独占一个缓存行：用
alignas(std::hardware_destructive_interference_size)修饰变量本身，或封装为独立对齐结构 -
std::hardware_destructive_interference_size在 GCC/Clang 较新版本中可用，但 MSVC 2019 及更早默认未定义，需配合宏检查回退到 64 - 数组场景下，对齐单个元素还不够，要确保
sizeof(AlignedCounter)≥ 缓存行大小，否则数组相邻元素仍会挤进同一行
填充（padding）和 alignas 哪种更适合计数器数组？
优先用 alignas，填充易出错且维护成本高。比如手动写 char padding[56] 依赖 sizeof(int64_t)，一旦成员类型变更就失效。
立即学习“C++免费学习笔记（深入）”；
但要注意数组声明方式：
alignas(64) std::atomic<int64_t> counters[8]; // ✅ 每个元素强制对齐，间距至少64字节 std::atomic<int64_t> counters[8]; // ❌ 即使结构体对齐，数组仍是连续紧凑布局
- 若用结构体数组，必须让结构体自身满足缓存行大小：
struct alignas(64) Counter { std::atomic<int64_t> val; };</int64_t> - 避免在结构体内混放读写频率差异大的字段——比如把只读配置和高频写计数器放在同一结构体，即使对齐了也会浪费缓存带宽
- 大数组（如每核一个计数器 × 数百核）慎用对齐，内存膨胀明显；此时可考虑线程本地存储（TLS）+ 最终归并，而非全量对齐
为什么用了 alignas 还有伪共享？
常见原因不是对齐失效，而是变量实际访问路径未隔离。典型漏点：
- 全局变量或静态变量被多个线程通过不同函数访问，但它们在数据段中物理地址相邻——需统一用
alignas声明，不能只对部分变量对齐 - 结构体对齐了，但被嵌套在另一个未对齐的大结构中，导致偏移量破坏对齐效果
- 使用
std::vector<AlignedCounter>时，vector内部内存由allocator分配，默认不保证按缓存行对齐；应搭配自定义分配器或改用std::array - 调试时用
printf或日志打印变量地址，可能干扰编译器优化和内存布局，导致测试结果失真；性能验证务必关闭调试输出、启用-O2/-O3
真正关键的不是“有没有对齐”，而是“写操作是否真的落在不同缓存行”。最稳妥的方式：用 perf stat -e cache-misses,mem-loads,mem-stores 对比优化前后指标，确认缓存未命中率下降、总线流量减少——这比看代码对齐更可靠。
