伪共享是多线程程序中因不同线程修改同一缓存行内不同变量，触发缓存一致性协议频繁同步而导致的性能下降；需通过填充、对齐或线程局部存储等方式隔离独写变量。
False sharing（伪共享）是多线程 C++ 程序在多核 CPU 上性能下降的常见隐形杀手——它不是代码逻辑错误，而是缓存系统“太聪明”导致的意外竞争。
什么是伪共享？
现代 CPU 每个核心都有自己的 L1/L2 缓存，而缓存以 缓存行（cache line） 为单位加载数据（通常是 64 字节）。当两个线程分别修改同一缓存行中不同变量时，即使它们互不干扰，也会因缓存一致性协议（如 MESI）反复使对方缓存行失效，强制重新同步——这种无意义的缓存行争用就是伪共享。
举个例子：
struct Counter {
int a; // 线程 1 写
int b; // 线程 2 写
};
若 a 和 b 恰好落在同一 64 字节缓存行内，两个线程高频更新就会触发频繁的缓存行无效化与重载，性能可能暴跌数倍。
立即学习“C++免费学习笔记（深入）”；
如何识别伪共享？
它不会报错，但会表现为：
• 多线程加速比远低于预期（甚至比单线程还慢）
• CPU 使用率高，但实际吞吐低
• perf 或 VTune 等工具显示大量 LLC-load-misses、remote-node-loads 或 cache-references 异常升高
简单验证法：把疑似共享的变量手动隔开（比如加 64 字节填充），再测性能。如果明显变快，大概率就是伪共享。
C++ 中避免伪共享的常用方法
核心思路：让高频独写变量各自独占缓存行（或至少不与其他独写变量挤在一起）。
手动填充（Padding）：用 alignas(64) + 填充数组隔离变量
struct PaddedCounter {
alignas(64) int a;
char _pad1[60]; // 确保下一个变量不在同一行
alignas(64) int b;
};使用 std::hardware_destructive_interference_size（C++17）：
这是标准推荐方式，值通常为 64（x86-64），但可移植性更好：
struct Counter {
int a;
char _pad1[std::hardware_destructive_interference_size – sizeof(int)];
int b;
};按线程分组分配：每个线程操作独立内存块（如 thread-local storage、per-thread ring buffer），从源头避免跨线程访问邻近地址避免结构体中混放热/冷字段：把频繁写的字段集中放在开头，用 padding 隔开；不常访问的字段（如调试计数器、状态标志）挪到后面或单独结构体中
需要注意的误区
• alignas(64) 不等于防伪共享：它只保证变量起始地址对齐，不保证后续成员不落入同一行。真正有效的是“变量之间留足间隔”。
• 过度隔离浪费内存：每个变量都 pad 到 64 字节，在大数据量场景下显著增加内存占用和 cache footprint，需权衡。
• 只对写操作敏感：多个线程只读同一缓存行完全没问题（共享只读数据是缓存设计的本意）；伪共享本质是“写-写冲突”。
基本上就这些。伪共享不复杂，但容易忽略——尤其在追求极致并发性能时，它常是压测瓶颈背后那个沉默的元凶。
以上就是c++++中的false sharing(伪共享)是什么_c++多核缓存行问题与解决方案【并发】的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1489826.html
微信扫一扫 
支付宝扫一扫 
