DoubleAddr通过alignas(64)为每个线程分配独占缓存行的计数器，从内存布局上消除伪共享；而std::atomic并排声明易使变量落入同一缓存行，触发MESI协议频繁失效重载，导致性能随线程数非线性恶化。
DoubleAddr 本身不是标准库函数或通用术语，而是指一种分段累加（double-buffered accumulator）设计模式：用多个独立缓存行隔离的计数器，通过轮转写入+定期合并来规避伪共享。它不依赖原子操作争抢同一缓存行，而是从内存布局上消灭争抢源头。
为什么 std::atomic 直接并排声明会触发伪共享
两个 std::atomic<long long></long> 变量若在内存中紧邻（如 struct { std::atomica、线程 B 写 b，CPU 缓存一致性协议（MESI）会强制将整个缓存行在核心间反复失效、重载——即使变量逻辑上完全无关。
- 典型现象：多线程递增计数器时，总耗时随线程数增加非线性上升，甚至 2 线程比 1 线程还慢
- 验证方法：用
perf stat -e cache-misses,cache-references观察 cache-misses 比例飙升 - 根本原因：64 字节缓存行是硬件最小同步单位，无法按字段粒度隔离
DoubleAddr 的核心做法：对齐 + 分段 + 合并
不是“一个计数器双缓冲”，而是为每个线程/核心分配**独占缓存行**的计数器，再由单一线程汇总。关键在内存隔离，不在缓冲机制。
- 用
alignas(64)强制每个计数器独占缓存行：struct alignas(64) PaddedCounter { std::atomic<long long> value{0}; }; - 声明数组而非结构体成员：
PaddedCounter counters[4]; // 4 个线程，各占 64 字节，物理地址至少相隔 64 字节
- 线程只写自己索引的
counters[tid].value，绝不跨写 - 统计阶段由主线程遍历累加：
total += counters[i].value.load(std::memory_order_relaxed);
容易被忽略的对齐陷阱
仅用 alignas(64) 不够，还需确保数组起始地址本身对齐——否则第一个元素可能跨缓存行，连带影响后续。
- 全局/静态数组通常满足要求；但堆上分配需显式对齐：
auto* counters = static_cast<PaddedCounter*>( aligned_alloc(64, sizeof(PaddedCounter) * 4) ); - 若使用
std::vector，必须自定义分配器，否则new返回地址不保证 64 字节对齐 - 结构体内嵌时，
alignas(64)仅约束该字段偏移，不保证其内部数据不与相邻字段共享缓存行——所以必须让目标变量成为结构体唯一成员，或用填充字段隔离
和普通 atomic 对比的性能差异点
伪共享不是“慢一点”，而是“随着并发度上升，延迟呈指数级恶化”。DoubleAddr 模式把争抢从运行时转移到合并阶段，而合并是串行、低频、可批量化的。
- 写路径：无锁、无缓存行失效、纯本地 cache hit，延迟稳定在 ~20 ns（x86-64）
- 读路径：合并成本固定，O(N) 但 N 是线程数（通常 ≤ 64），远低于持续伪共享导致的 cache miss 开销（~100 ns+）
- 内存开销：4 线程需 256 字节，相比未对齐的 16 字节虽增 15 倍，但换来的是可预测的线性扩展能力
真正难的是确认你的热点变量是否真的被不同核心高频修改——很多所谓“伪共享”其实是误判：变量实际由单一线程更新，或访问频率低到 cache miss 影响可忽略。先用 perf 验证 cache-misses 是否集中在目标地址，再动手改内存布局。
