C++实现高性能并发计数器 _ std::atomic与缓存行填充优化【源码】-C++-PHP中文网

会，std::atomic 直接使用极易引发 false sharing；多个原子变量若位于同一缓存行（如结构体中相邻或数组连续），一核修改会导致其他核缓存行失效，性能骤降。

c++实现高性能并发计数器 _ std::atomic与缓存行填充优化【源码】

std::atomic 直接用会遇到 false sharing 吗？

会，而且非常容易。只要多个 std::atomic 变量在内存中挨得很近（比如放在同一个 struct 里或连续数组中），它们就可能落在同一个缓存行（通常是 64 字节）里。一个线程改其中一个，会导致整个缓存行失效，其他 CPU 核心上缓存了同一线的其他原子变量也得重新加载——性能直接掉一个数量级。

典型症状：单线程跑很快，一加到 4+ 线程，吞吐不升反降，perf stat -e cache-misses 显示 cache-misses 暴涨。

默认情况下，std::atomic 大小就是 4 字节，没 padding
即使你用 alignas(64) 对齐变量起始地址，也不等于它独占整条缓存行——后面紧跟着的变量仍可能被塞进来
struct 成员顺序很重要：把要隔离的原子变量放一起，再手动填充

怎么给 std::atomic 做缓存行填充？

核心思路是：让每个需要高并发读写的 std::atomic 占满一整条缓存行（64 字节），前后都用填充字节隔开。不是对齐，是“占位”。

推荐写法：

struct alignas(64) PaddedCounter {
    std::atomic<long> value{0};
    char _pad[64 - sizeof(std::atomic<long>)]; // 确保整个 struct 是 64 字节
};</long></long>

注意：alignas(64) 是必须的，否则编译器可能把多个 PaddedCounter 实例紧凑排布；_pad 大小要严格算清——sizeof(std::atomic) 在多数 x86_64 上是 8，所以填 56 字节。

别用 std::vector 存大量计数器——虽然每个实例独立，但 vector 内存连续，首地址对齐后，第 2 个实例大概率还在同一缓存行边界内（取决于分配起始地址）
更稳妥的做法是用 std::unique_ptr 配合 aligned_alloc(64, ...) 手动分配
如果只是几个全局计数器，直接定义为全局变量或 static 成员，alignas(64) 就够用

std::atomic::fetch_add 性能瓶颈在哪？

不是指令本身慢，而是内存序（memory order）选错。默认 fetch_add 用的是 std::memory_order_seq_cst，它要求全局顺序一致，在多核下需频繁同步 store buffer 和 invalidate queue，开销大。

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

如果你只关心计数值最终一致、不依赖与其他变量的执行顺序（绝大多数计数场景都是），可以降级：

counter.fetch_add(1, std::memory_order_relaxed);

std::memory_order_relaxed：无同步无顺序约束，纯本地寄存器+cache 操作，吞吐最高
std::memory_order_acquire/release：适合读写配对的同步点（如 start/stop 标记），不适用于单纯累加
千万别在读取最终值时还用 relaxed——比如日志打印前要用 load(std::memory_order_acquire) 或保持默认，否则可能看到过期值