伪共享是因多线程修改同一缓存行中不同变量导致频繁缓存同步的现象。CPU以64字节缓存行为单位管理内存，当一个核心修改变量时，整个缓存行被标记为已修改，使其他核心对应缓存行失效。即使变量逻辑独立，若物理上位于同一缓存行，就会引发反复同步，降低性能。典型场景如两个线程分别递增相邻的计数器a和b，若未隔离则互相干扰。可通过perf等工具检测缓存未命中率，结合性能随线程增加而下降的现象判断。解决方法包括：使用alignas(64)对结构体进行缓存行对齐；手动填充padding保证变量分属不同缓存行；或将共享变量分离到独立对齐结构体中。优化时应聚焦高频写入场景，避免过度填充浪费内存，且在NUMA系统中更需注意其影响。理解并规避伪共享是提升C++多线程性能的关键。
在C++多线程编程中，你可能会遇到一个奇怪的现象：明明增加了线程数，程序性能却没有提升，反而变慢了。这背后很可能就是“伪共享”（False Sharing）在作祟。它和CPU缓存机制密切相关，尤其在高频访问共享数据的场景下，影响尤为明显。
什么是伪共享（False Sharing）？
现代CPU为了提高访问速度，将内存按“缓存行”（Cache Line）为单位进行管理，通常大小为64字节。当一个核心修改某个变量时，即使该变量只是整个缓存行中的一小部分，整个缓存行也会被标记为“已修改”，并通知其他核心使其本地缓存失效。
伪共享就发生在多个线程频繁修改位于同一缓存行中的不同变量时。虽然这些变量逻辑上彼此独立，但由于它们物理上挤在同一缓存行里，每次修改都会导致缓存行在核心间反复同步，造成大量不必要的性能损耗。
red">典型示例：
立即学习“C++免费学习笔记（深入）”；
假设有两个线程分别递增两个不同的计数器：
struct Counter {
int64_t a; // 线程1修改
int64_t b; // 线程2修改
};
如果 a 和 b 被分配在同一个64字节缓存行中，即使它们毫无关联，两个线程的操作仍会互相干扰，引发频繁的缓存失效，拖慢整体速度。
如何检测伪共享？
伪共享难以通过代码直接察觉，但可通过以下方式辅助判断：
- 使用性能分析工具（如perf、Intel VTune）观察缓存未命中（cache miss）情况，特别是
L1D.REPLACEMENT或MEM_LOAD_RETIRED.L1_MISS指标异常高。 - 线程增加后性能不升反降，且热点集中在对小变量的读写操作。
- 将原本相邻的变量手动隔离后性能显著提升。
解决方法：缓存行对齐（Cache Line Alignment）
最有效的应对策略是确保被不同线程频繁修改的变量位于不同的缓存行中，避免共享同一缓存行。C++ 提供了多种实现方式：
1. 手动填充（Padding）
struct alignas(64) PaddedCounter {
int64_t a;
char padding[64 - sizeof(int64_t)]; // 填充至64字节
int64_t b;
};
这样 a 和 b 分属不同缓存行，互不影响。
2. 使用结构体分离 + 对齐说明符
struct alignas(64) ThreadLocalData {
int64_t value;
};
// 每个线程使用独立实例，天然隔离
ThreadLocalData data[2];
3. 利用标准库或宏简化操作
可定义通用宏来简化对齐操作：
#define CACHELINE_SIZE 64
#define ALIGNAS_CACHELINE alignas(CACHELINE_SIZE)
<p>struct ALIGNAS_CACHELINE CounterAligned {
int64_t a;
};</p><p>struct ALIGNAS_CACHELINE {
int64_t b;
};
实际建议与注意事项
- 只对高频写入的共享变量做对齐处理，避免盲目填充浪费内存。
- 读多写少的场景伪共享影响较小，不必过度优化。
- 注意结构体默认对齐可能不足以防止伪共享，必须显式控制。
- 在NUMA架构或多插槽系统中，缓存一致性开销更大，伪共享危害更严重。
基本上就这些。伪共享是一个隐蔽但破坏力强的问题，理解缓存行机制并合理使用对齐技巧，是写出高性能C++多线程程序的关键一步。不复杂但容易忽略。
