伪共享是多线程下因变量同处一缓存行导致的性能问题，当多线程修改逻辑独立但物理相邻的变量时，引发频繁缓存同步，表现为吞吐量不升反降、缓存未命中率上升；可通过结构体填充、alignas对齐、数组间隔布局或线程本地存储等方法隔离写操作，结合硬件缓存行大小（如std::hardware_destructive_interference_size）进行优化，重点应用于高频写入场景以平衡性能与内存开销。
在C++多线程编程中，伪共享（False Sharing）是影响性能的一个常见但容易被忽视的问题。它发生在多个线程操作不同变量，而这些变量恰好位于同一个CPU缓存行中，导致缓存频繁失效，从而降低程序效率。
什么是伪共享？
现代CPU为了提高访问速度，会将内存按“缓存行”（Cache Line）为单位加载到高速缓存中，通常大小为64字节。当一个核心修改了某个缓存行中的变量，整个缓存行会被标记为无效，其他核心即使访问的是该行中不同的变量，也必须重新从内存加载。
例如：两个线程分别修改位于同一缓存行的变量 a 和 b，虽然逻辑上无冲突，但由于共享缓存行，会导致反复的缓存同步，这就是伪共享。
如何识别伪共享问题？
性能表现特征：- 多线程吞吐量没有随核心数增加而提升，甚至下降
- CPU缓存未命中率显著升高
- 使用性能分析工具（如perf、Intel VTune）可发现大量缓存一致性流量
代码典型场景：
立即学习“C++免费学习笔记（深入）”；
struct Counter {
int64_t a; // 线程1写入
int64_t b; // 线程2写入
};
若两个线程分别对 a 和 b 进行频繁写操作，由于它们可能处于同一缓存行，就会产生伪共享。
避免伪共享的常用方法
核心思路是：确保被不同线程频繁写入的变量不在同一个缓存行中。
1. 手动填充（Padding）
通过添加填充字节，使每个变量独占一个缓存行。
struct PaddedCounter {
int64_t value;
char padding[64 - sizeof(int64_t)]; // 填充至64字节
};
若用于数组，每个元素都应独立占据缓存行。
2. 使用对齐属性（alignas）
C++11起支持 alignas，强制变量按缓存行对齐。
struct alignas(64) AlignedCounter {
int64_t value;
};
这样即使结构体较小，也会占用完整缓存行，避免与其他数据共享。
3. 数组布局优化
对于计数器数组等场景，不要让每个线程写相邻元素。
// 每个线程使用间隔至少64字节的槽位 alignas(64) int64_t counters[NUM_THREADS][8]; // 每行64字节 // 线程i使用 counters[i][0]
或使用一维数组并手动跳过缓存行：
int64_t* counters = new int64_t[NUM_THREADS * 8]; // 线程i访问 counters[i * 8]
4. 使用线程本地存储（TLS）
每个线程先累加本地副本，最后合并结果，从根本上避免共享写入。
thread_local int64_t local_sum = 0; <p>// 工作循环中 local_sum += delta;</p><p>// 最终合并 global_counter.fetch_add(local_sum);
适用于累加、统计类场景，效果显著。
实际建议与注意事项
伪共享主要影响频繁写入的场景，读操作影响较小。优化时注意：
- 不是所有共享变量都需要padding，只针对高频写入且跨线程的变量
- 过度填充会浪费内存，需权衡空间与性能
- 缓存行大小因平台而异（多数为64字节），可用 std::hardware_destructive_interference_size 获取（C++17起）
#ifdef __cpp_lib_hardware_interference_size
constexpr size_t cacheline_size = std::hardware_destructive_interference_size;
#else
constexpr size_t cacheline_size = 64;
#endif
基本上就这些。关键是在设计并发数据结构时，有意识地隔离线程间的写操作，合理利用对齐和本地存储，就能有效规避伪共享带来的性能陷阱。
