伪共享不是编译器或语言层面的 bug，而是多线程程序在现代 cpu 缓存架构下必然出现的性能陷阱；它无法“自动避免”，必须通过显式内存布局控制来隔离高频写变量——最可靠、最常用的方式是 alignas 对齐到缓存行边界。
直接说结论：伪共享不是编译器或语言层面的 bug，而是多线程程序在现代 CPU 缓存架构下必然出现的性能陷阱；它无法“自动避免”，必须通过显式内存布局控制来隔离高频写变量——最可靠、最常用的方式是 alignas 对齐到缓存行边界。
为什么 alignas(64) 是首选方案
主流 x86-64 和 ARM64 CPU 的缓存行大小为 64 字节，alignas(64) 能确保变量起始地址严格落在 64 字节边界上，从而大概率让两个被不同线程写的变量落入不同缓存行。
- 它比手动填充（
char padding[56]）更简洁、不易出错，且不依赖结构体成员顺序 - 对结构体整体对齐（如
struct alignas(64) Counter { int64_t value; };）比仅对单个成员对齐更稳妥，避免编译器因填充策略导致意外偏移 - 注意：对齐只影响变量起始位置，不保证整个对象不超过 64 字节；若结构体本身大于 64 字节（比如含多个字段），需额外评估是否仍存在内部跨字段伪共享
std::hardware_destructive_interference_size 该不该用
这个 C++17 标准常量本意是提供可移植的缓存行干扰尺寸，但实际支持度有限：GCC 10+、Clang 9+ 基本可用，MSVC 2019 起支持，但 macOS 上长期未实现（Apple Clang 仍返回 0 或未定义）。
- 生产代码中建议用宏兜底：
#if defined(__cpp_lib_hardware_interference_size) && !defined(__APPLE__) - 回退到
64是安全选择，目前尚未有主流通用 CPU 使用非 64 字节缓存行（部分嵌入式或老架构除外，但通常不在高性能并发场景中） - 不要把它当作“银弹”——它只是对齐尺寸建议值，不能替代对热点变量的识别和布局设计
哪些变量必须防伪共享，哪些可以不管
伪共享开销只在“多线程高频写 + 同缓存行 + 逻辑无关”时显著爆发。不是所有共享变量都值得加对齐。
- 重点防护：统计计数器（
std::atomic<int64_t></int64_t>）、状态标志（std::atomic<bool></bool>）、队列头/尾指针（如 MPMCQueue 中的head/tail） - 无需防护：只读变量（即使同缓存行也无 MESI 写无效开销）、低频更新字段（如配置项每秒改一次）、被同一线程读写（无跨核同步压力）
- 警惕数组：
std::array<counter n></counter>若每个Counter未对齐，相邻元素极易伪共享；应使用alignas修饰模板实例或用间距分配
线程局部存储（TLS）是不是更优解
对纯累加类场景（如性能计数），thread_local 确实比对齐更彻底——它把变量完全移出共享域，既免伪共享，也免原子操作开销。
- 适用前提：结果可合并（如最后做
global += local），且线程生命周期稳定（避免 TLS 析构竞争） - 不适用场景：需要实时可见性（如状态标志必须立即被其他线程感知）、跨线程通信（如信号量、条件变量）
- 注意 TLS 初始化开销：首次访问可能触发动态初始化，高并发启动阶段可能成为瓶颈点
真正难的是判断“哪里发生了伪共享”——它不报错、不崩溃，只默默拖慢吞吐。没有 perf 或 VTune 的采样数据，光靠对齐容易过度设计；而完全忽略，又可能在线上压测时突然掉 30% 性能。动手前先用 perf stat -e cache-misses,cache-references 看看缓存未命中率是否异常高，再决定在哪加 alignas。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
